Basics for an EnginE?

[Sonikku`]

I wanted to make a Zelda clone(SNES version, forgot name). It wouldn't be to hard, would it? Its just a moving sprite over various backgrounds, which some have certain properties(like being a waLL etc). Right?

[Fox]

No. Zelda 3 (A Link to the past) is a good game and every good game needs a lot of time to develop. The graphics may be simple, the engine isn't that hard, but there's still a lot of work behind it. Don't underestimate SNES games, they're all very quality products. Even Zelda has many things where you can get stuck, ie. the items or story system. Also as you're asking other people if a project would fit to you it won't. You should be able to self-decide whether you're able to do something or not. If not, you're not. And by the way: Zelda has no backgrounds, it's a pure tile engine.

[Sonikku`]

Tile Engine Huh, thx for Info.

[scr0p]

What kind of a background does a game like Sonic2 for Genesis use? all I have now is the sonic sprite (From soniKKu`) and I want to make 1 sonic level (not the background, I mean full level with background, enemies and items..etc I know it wnt be easy)

[Fox]

That's also a tile engine. You know those older consoles (NES, SNES, MegaDrive, MasterSystem, Genesis, aso.) are all optimized for tile engines. Most games are based upon one.

[scr0p]

What is a tile engine? right now I have a windowed mode DX7 app, and I haev a sprite on it that can move around adn whatnot, but I want a background behind it, how would I add one?

[Fox]

The tile engine is the part that draws your background ) Basically you split up the background in single graphics called tiles, they're like 32x32 or 64x64 pixels in size. The idea is that you fill the screen using these tiles, simple because you can decide which tiles to draw and which not. Also you can save a lot of memory - imagine a simple repeating background that is 2000x1000 in size. That's relly small since it's repeating during the whole level. You can now replace this big picture by tiles, ie. you have a 'cloud' tile, some different sky colors and 3 or 4 simple earth tiles - you can build up as big pictures as you want by combining those small numbers of tiles. For more information check out my tutorial which shows you the basics of a 2D tile engine. Remember that it doesn't matter wheter the tile engine is used for a top-view RPG or a side-view Jump'n'Run. Also collisions can be done veeery easy with a tile engine. That's 3 Points for the tiles, check it out

http://fox.acky.net/vb/english/coding/tutorial/4.html

[scr0p]

That's what I thought it was, hmM, I guess I see how it works now, I was thinking of a different concept for a game like sonic. I will read your tutorial when I get a chance, thanks.

I have a question, how do I make a bitmap show over a BG animated? I can animate a bitmap, and show a bitmap, (in full or windowed mode) but I cant do them both together, do I use bltfast or something?

[Fox]

Basically you draw the background in each frame and all sprites over it. Probably particles and a GUI, too. When everything is done you copy the whole frame to the screen which is called double buffering. Unless you want to take care about what changes in each frame you should use DBuffering. A sample where you shouldn't use DB is a game like tetris where most parts of the screen never change - so you can just overdraw the 2 or 3 sprites that are moving/changing. However for any Jump'n'Run or RPG engine you need double buffering. Here's again the drawing queue:

1) Draw the very background to the buffer (this maybe a static bitmap that is screen size)

2) Draw the (slow moving) background to the buffer, this is the first tile "layer"

3) Draw another (fast moving) background to the buffer, this will give you a 3D-effect called 'parallax scrolling' - the idea is you move 2 BGs in different speed, therefore it looks kinda 3 dimensional.

4) Draw the level (map) layer to the buffer - this is the layer your player collides with and walks on.

5) Draw the sprites to the buffer, includes player, enemies, in-game items, shots, aso.

6) Draw the 'foreground' (map) layer to the buffer - this layer is exactly the same like 4) excepting the tiles are drawn over the player. This looks quite nice and if you don't use this layer you cannot walk 'behind' trees or something in your game.

7) You might want to have another "fast" foreround layer to the buffer which makes it again look more 3D. This layer should not contain much tiles, ie. just some plants that are 'near the screen'.

8) The last layer is the GUI, you know the number of lifes, coins, items, aso. This layer also won't move but since it's drawn over everything you can't optimized this by using tiles. Just draw your GUI elements where they are needed.

9) Copy the whole buffer to the screen in one call, I'm calling this "Flipping". Flipping is not exactly correct since that was a older technique for DOS games. The idea is to switch between 2 buffers as soon as you've prepared them, except of copy them to the screen you just change the 'source' of the screen so it simply displays another buffer in each frame (which of course is very fast but kinda depraced).

Note that I explained really a lot now - when using BitBlt you might get into performance problems drawing that much layers. In a simple game you might just want to draw the 2 map layers, the sprites and a GUI.

[Sonikku`]

So All it is, is various "Tiles" the same size as the viewable area that moves according the movement. KoOL,.

oH bTW I was having that Animating over a background problem to.~

[scr0p]

Note that I explained really a lot now - when using BitBlt you might get into performance problems drawing that much layers.

bitBLT is the API or are you also refering to DX .blt too?

---

You explain a lot and I get the concept now, but I need code, and what is the diff between backbuffer and offscreenplain, also what is backbuffercount, if I need it.

[Sastraxi]

BitBlt is quite inefficient for small transfers and lots of them...

Backbuffer: The thing you are going to blit to, and this will be "flipped" to the Primary surface you also defined, in the method Fox has already explained.

Offscreenplain: Just a surface that's only visible by blitting.

Backbuffercount: I don't think you need this... though I'm not sure... I think it's usually set to 1, I can check though.

[Sonikku`]

Could someone explain to me what the word "Caps" does and make sense of this code please. thx.

Dim caps As DDSCAPS2 
caps.lCaps = DDSCAPS_BACKBUFFER 
Set backbuffer = primary.GetAttachedSurface(caps) 
backbuffer.GetSurfaceDesc ddsd3

[Fox]

Backbuffercount
You can use more than 1 backbuffer, this can be usefull if your game draws faster than excepted. In this case you can 'pre-draw' the coming frames and use the CPU time left for things like AI and game stuff. ...don't care about this yet

Caps
Short for 'capabilities'. Use the caps to check if your device supports several features or not. Thus you can exactly adjust your game to the available features of the users graphic card, sound card, and such. For example you can get the screen modes (resolutions and refresh rate) or the alpha-bits your device supports. According to the caps you can optimize your engine, ie. if the device doesn't support alpha transparency you can try to simulate this 'by hand' (using the CPU and your own renderer) or just turn it off completely. Again, don't care about this yet.
In the code fragment you posted you use the caps the other way around, to enable backbuffering for the specified surface, meaning you can set the caps you need.