Graphics Display Memory Leak?
amoSpin
Posts: 16
I am trying to write a video game for the c3 board, using a monitor and VGA. Here is my code so far. When I run this program, however, the screen fills with garbage. I have searched the code, but I can't find a memory leak. The section where the sprites are defined is a likely culprit, though. I got that format from "Game Programming for the Propeller Powered HYDRA", but I am not sure how it works, and it could be the source of the problem. Any help would be greatly appreciated.
I will post the objects I am using as soon as I can. Thanks!
Comments
Here are the objects I used. Thanks!
Don't have any hardware set up at the moment to properly test what's going on, but as posted, your code should be drawing nothing? If you could post a picture of the garbage graphics that might help.
There is however an obvious memory issue (that shouldn't affect anything as is, but oh well)
repeat idx from 0 to 20 missiles[idx] := INACTIVEThis (and similar code elsewhere) is incorrect, the
missilesarray has only 20 entries numbered 0 through 19, so accessingmissiles[20]is incorrect. Thus the loop should berepeat idx from 0 to 19. (Also, the number really shouldn't be hardcoded, use a constant).Also, that
_stackdefinition really shouldn't be commented out.Thanks for your advice. I updated the code. Now it doesn't print anything to the VGA screen, and my debug statements go all funny. Here's a picture of what the terminal looked like. The board also eventually restarts and runs the program I have saved in EEPROM. Here's the updated code. A lot of stuff is commented out because I am just trying to get the display to work, and don't want problems in other sections to interfere. Thanks!
That file doesn't even build for me due to memory overflow. Which I think is your issue. The program/variables/stack run beyond BITMAP_BASE and and thus get corrupted when you try drawing there. Which makes sense, since double-buffering a 256x192 frame takes up 24K out of the 32K RAM you have. If on top of that you put a lot of program and variables (esp. using long variables where byte would suffice), you just run out. This is sort-of an inherent problem with Graphics.spin and it's frame-buffering approach. If you take a gander at the example games that come with the Hydra book you will notice that only a few simple ones use it.
I noticed that when I tried to compile a previous version of this program with Propeller Tool (v1.3.2) it wouldn’t work due to memory overflow. When I switched to a newer version of Propeller Tool (2.7 Beta) it worked. I couldn’t figure out what was causing it to overflow, because it would compile and have mostly free space, and then adding a line or two would cause it to break due to memory overload.
Also, when compiled with Propeller Tool 2.7 Beta, the updated file says that it has 5,907 free longs. What did you try to compile it with?
In newer versions of proptool the memory limit check is busted. Use 1.3.2 for Propeller 1 purposes, there's no benefit to using 2.x versions.
To fit under the frame buffer, you'd need to have more than 6144 longs free.
Thanks for the advice. I tried commenting out some of the stack and other variables, and it worked. As you said, as long as I had more than about 6000 longs free, everything worked fine. The Propeller Tool v.1.3.2 would not compile the program with anything less than 6,169 free longs. Does Prop Tool V.1.3.2 know that I have overflowed into the video buffer section? Also, is there any reason why this number is not exactly the number you mentioned?
That's what the
_stackline constant does: Error out if there's less free space than it's value. ($3000 + $3000 + 100)>> 2 equals 6169.So the
_stackconstant just doesn’t work with any Propeller Tool besides 1.3.2? Thanks!Yea, just busted. IDK why it didn't get fixed yet.
Understood. Thanks so much for your advice!
The first thing you should do is check your code for any memory leaks or errors that could be causing the problem. You mentioned that you searched the code but couldn't find a memory leak, but it's worth double-checking to make sure.
The section of the code where the sprites are defined is a likely culprit, as you mentioned. If you're unsure how the format works, you may want to try a different format or consult the documentation for the "Game Programming for the Propeller Powered HYDRA" that you referenced.