Code:



As you can see in the screenshot it's not behaving like i think it should :/

(I want to be able to shoot image [000C021D020C0000] and leave nothing but the cursor behind.)

Any help or optimizations are appreciated.

Credit to the SHMUP tutorial here for starting me out
http://www.cemetech.net/forum/viewtopic.php?t=9695

I have looked over your code and applied some bugfixes and some basic code form improvements. The bugfixes mainly had to do with bullet handling, as would probably be expected from your screenshot. The main non-bugfix change I made was to change the renderer to render each frame from scratch instead of undrawing and redrawing things that moved. I believe you'll find this change will make your life a fair amount easier. Other changes included removing unnecessary code (at least, it looked unnecessary), initializing the data in L₁ to 255 instead of 0, (in turn allowing simplified bullet processing to only process bullets with X coordinates less than 96,) and making bullets spawn exactly at the ship's position rather than in front of it (more of a personal preference).

The 8xp of my changed code can be found here, and you can see the SourceCoder-ized code below:


Code:



And in case you want to give yourself a headache, I went a bit further and you can find a heavily optimized version here, or below:


Code:

This is very nice code and it would be no problem to use if i were making something like a space shooter . The problem is i was going to make a sidescroller with physics and a map and i don't know if there is a way to not have to redraw the map every frame as this would slow down the game quite a bit.

You can still make a sidescroller without having to redraw the whole map every frame. This is commonly done by keeping the map (and the map only) in a separate drawing buffer, shifting it around and redrawing data shifted in as necessary, and simply copying this buffer to the main drawing buffer at the start of rendering every frame. To put into perspective how much time this takes, copying one buffer to another in memory is about four times faster than copying a buffer to the screen (DispGraph). So this method adds a small constant time to each frame rendered, but subtracts a linear amount of time from sprite rendering and generally makes it easier because you don't have to keep track of every sprite that was drawn and erase ones that have moved. This sprite erasing process becomes even more complicated/slow if you draw sprites with logic other than XOR via Pt-Change(), which I believe you may soon find you'll want to do anyways because XOR'ing sprites onto a background image that is not just plain white or black can look weird.