Space Shooter Game Editor

[SilverWarior]

Hi,

I can't sleep, I've coded a bit, added AnimStart variable to my map data... you can set animstart for each tile, so the latest attached editor can make certain tiles be synced, and other tiles see them lights do their animation from different starting position.
Also since now I'm only executing my DrawLevel and SyncAnim loop when the map is updated or moved.

If you execute this one, and load the included level02.map you'll see that water is perfectly synced, the lights which i wanted to be synced are synced, and those 3 lights are using different anim start position, so don't look like exact copies of
each other.

Nice work on this. But I still think that water animation gets out of sync when scrolling.

Next I'm planing to add for each animated sprite , animation speed, so I can have faster and slower lights, or faster slower water,fire...etc....

Yes this would be nice feature and could come verry handy in future.

I was thinking myself about the scrooling, unfortunately I cannot simply use BackGround[i,j].WorldX and WorldY , because I'm only drawing as many sprite's as I'm actually using for 1 screen...

I came up with a solution, which I think could work, I would create 1 more line of Sprite's , that would be beyond the screen height in the direction I'm moving.

Then I would move WorldY until I would rich the end of this aditional (hidden) line of Sprite's , once I rich the end of it I would move my entire BackGround[i,j].Images in the apropriate directions, and reset my WorldY to the original position.

Yes adding a new line of sprites for smoth scrolling is necessary. But I had a bit different idea of how to implement this. Instead of moving WorldY Position I would go and move the sprites instead. Why? If you move sprites instead you won't need to update all visible sprites when you have moved your map for the full line size but instead you go and destroy those sprites that are no longer needed and then make new line of sprites when they would be needed.

Since you are trying to make SpaceShooter game I presume you will be moving your gameworld downward. So the way how I would implement this scroling is like this.
1. First you create enough sprites to fill window size (similar as you do now).
2. Then you create another line of sprites above current ones.
3. You move all these sprites downward by certain amount of pixels.
4. Once you have repeted step 3 enough times so that you moved the world for entire line height you destroy botom line of sprites which aren't visible anymore now and then you create another line of spites at the top. After that you go back to step 3.
5. You repeat step 3 and 4 until you either reach the top of the map or reach a boss ship which temporarily halts your progression through map.
6. Then you either end the game if it is on end of the map or wait for the boss to be kiled.

The biggest advantage of this approach is that you are not updating the textures for existing Sprites (unles for animations) but you are just adding necessary new Sprites and killing (destroying) unnecessary ones.

Offcourse to make this work easier I would change the map structure to someting like this:

TTileData = record
  ImageIndex: Integer; //Stores the index for retriving necessary image from TAspyhreImages
  AnimationCount: Integer //Stores how many pictures does animation contains
  AnimationOffset: Integer; //Stores offset from global animation position
end;

TMapLine = Array[0..15] of TTileData; //Stores the whole line of cells asuming the map width is 15 tiles.

TMap = record
  Mapname: String;
  MapSize: Integer //Storing the map size in String type could lead to problems during conversion. Also storing in Integer type saves you some memory.
  TLines: Array of TMapLine; //Stores the whole map
end;

So with proper file handling routines you can now actually go and read the map data directly from file Line by Line and thus reduce Games memory consumption a lot and you gain the ability to have enourmus maps if needed.
Ofcourse implementing several Layers would reqjuire aditional change to this maps structure.

As for Sprites animations you can see that I used AnimationOffset variable in my suggested map code. The reason for this is the fact that I'm still thinking of having some Global variable to progress position of various animations so that when you are making new sprites you just set their proper aniamtion position and then leave your SpriteEngine to take care of your animations.
To put this in code I need to get my computer set to be ready to compile your program first. Yes I know I sad that I would do this as soon as I come home but the fact is that I came home preaty beat up today so I haven't got much motivation for programing. Tis also means that above code is still just out of my head and might have some syntax errors.