• Popular Now

• 12
• 27
• 9
• 9
• 20

Archived

This topic is now archived and is closed to further replies.

2d engine design philosophy

This topic is 5664 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

well ive come to a point where my 2d engine will almost do anything i want it to, but i need to organize it, maybe give it a little re design as far as how the interface to the designer looks and operates. at the current moment, i have the following classes: engine bitmap map tile camera everything starts with the camera, which could probably just be put into the engine, since it only contains some variables, but i left it out incase you wanted to create multiple cameras, then when rendering, the camera can shift all around the map, depening on which camera you pass in the render function. The render function takes the variables from the cameras, and renders the 2d scene according to their values. For instance, you could create a camera class, CurrentCamera, then create several cameras. Then pass CurrentCamera in the render function, but the current camera could be any of the other cameras you have created. I think this makes the system extremely flexible in that aspect. Next the engine is initialized, passing an initial camera. This is where one of my problems lie. The engine uses data from the camera to create a back buffer (virtual bitmap in system memory). The camera has variables like viewx, viewy, x, y, and vhalf. Viewx specifies the number of tiles going across on the render surface. For instance, 11x11 would be viewx = 11, viewy=11. This would make it so that rendering will render a 11x11 display. Vhalf is used to specify the middle of that. the middle of 11x11 is 5. Ok, so what if you create a camera that has a bigger view size? well the engine doesnt like it, thats for sure... Next we have the bitmap class. This is used to load two bitmaps, a regular bitmap, and a bitmap used for masking. These are loaded into two dc's, DC and MaskDc. When you need to draw something, you must use a dc that contains the graphics, thats what the bitmap class is for. You can obviously created multiple ones, and pass any of the bitmap classes you want in the rendering function. You can only have one bitmap class per render pass. I know this is limited, but so is GDI and its memory resources. After about 5 fairly good size bitmaps are loaded into DC's, GDI starts to slow down... Next we have the Map. The map is nothing but an array of tiles. So lets talk about a tile. A tile contains srcx, srcy, width, and height, and a render function. Srcx tells where the x position should start in the Bitmap DC for rendering. Srcy tells where the y position should start in the bitmap dc for rendering. Width and height tells how far right, or down, it should go from the x,y position when it renders. The render function of a tile takes an engine, a camera, and a bitmap. The reason is that it blits the part of the bitmap specified by the tile, using information from the camera, into the dc of the engine(which is a back buffer). Then the engine can render to any dc you want it to, cuz its just blitting from a back buffer to the dc you specify. The formula i used to render a tile, is the following map(x,y) is a two dimensional array of tile class we use c.x (Camera x) plus the current ix in the for loop, minus half of the view size
ix as long
iy as long
for ix = 0 to (c.viewx-1)//we start with 0, so subtract one
for iy = 0 to (c.viewy-1)//11x11 would be 0 - 10 x 0 - 10
map(c.x + ix - c.vhalf,c.y + iy - c.vhalf).Render
next
next

Some parameters are passed into the render function of course, but i am just using this as an example Anyways, what can be done to possible improve my system, and possibly fix some of the problems i have addressed? Thanks, --Fireking Owner/Leader Genetics 3rd Dimension Development [edited by - fireking on September 7, 2002 8:34:16 PM]

Share on other sites
The very first thing that can be done to improve performance is to use DirectDraw rather than GDI, unless there is some logical reason not to. This will allow you to get around that bitmap limit you have and do some serious blitting.

For the camera, don''t limit backbuffer creation to one camera. Instead, let the backbufer remain a constant size, but use the camera to create different viewports. A viewport could be interpreted as a rectangular area on the back buffer where the blitting will be done, or as a seperate blitting surface (in DirectDraw). This will allow you to change view sizes with ease.]

Share on other sites
so if i made the backbuffer the size of the current screen resolution, then the camera''s could change to any size being full screen, or part of the screen.

would that be a performance hit?

and what about reintializing the back buffer when the camera size changes (i dont know how i could detect if it changed or not, because the function is called alot, maybe with a camera stored in the engine, kept track of on each change)

the latter sounds like the best solution to me, and the most effecient

--Fireking

Genetics 3rd Dimension Development

Share on other sites
quote:
Original post by Aldacron
The very first thing that can be done to improve performance is to use DirectDraw rather than GDI, unless there is some logical reason not to. This will allow you to get around that bitmap limit you have and do some serious blitting.

For the camera, don''t limit backbuffer creation to one camera. Instead, let the backbufer remain a constant size, but use the camera to create different viewports. A viewport could be interpreted as a rectangular area on the back buffer where the blitting will be done, or as a seperate blitting surface (in DirectDraw). This will allow you to change view sizes with ease.]

oh i wanted to mention that i do not like direct draw. This may sound very nieve(i cant spell), but i dont like its interface, or the way it works. There is simply too much that needs to be done in order to just draw a shape or something. I dont like using base codes either (a base or frame work someone created to work off of). I like understanding everything im doing when i program, and i like doing all of it my self. I took a lot of time on the GDI, because ive seen several successful examples that use the GDI that are doing what i am attempting to do (a tile engine, basically). Gdi is really a great thing, and I wish that more people wouldnt frown apon it. You want to draw something? EASY 5 steps! Its great! Im not putting direct draw or direct x down, im just saying that I PERSONALLY do not like it. Especially since direct x 8.1 requires that you know something about 3d programming in order to do 2d (you are rendering on quads or something like that). Again, im not putting down 3d accelerator rendering of 2d, but I PERSONALLY do not like it.

Ok enough babbling,

--Fireking

Genetics 3rd Dimension Development

Share on other sites
For DirectDraw7, highly compatible initialization code is the hard part. But after that?

You want to draw something? EASY! 4 to 6 simple steps!

It''s easy to learn, and it is very fast. It''s just sometimes a _bitch_ to get it up and running in the first place.

Share on other sites
For DirectDraw7, highly compatible initialization code is the hard part. But after that?

You want to draw something? EASY! 4 to 6 simple steps!

It''s easy to learn, and it is very fast. It''s just sometimes a _bitch_ to get it up and running in the first place.

Oh, by the way. Having a backbuffer and viewports will give a smaller performance hit than re-creating the backbuffer each time the camera size changes...

Share on other sites
Thats what wrappers are for, you spend maybe an hour or two writing some good functions to clean up all the ugly directdraw code and then you have the same "ease of use" (i guess) of GDI. Except you can handle more then 5 bitmaps at a time with DirectDraw =P

Share on other sites
You do not need to do use DX 8 if you have the DX 8 SDK. You can still use DirectDraw 7.

As far as the backbuffers go, option 1 which I suggested is much more efficient than option 2 in DDraw. For GDI, I haven''t a clue. I haven''t touched GDI in years.

I respect the fact that you like to do things yourself. I''m the same way And you can make some nifty games with pure GDI, but you mentioned yourself that ''GDI starts to slow down'' after 5 good sized bitmaps are loaded. This is exactly the issue DDraw was originally created to address. Sorry I can''t help you more. If no one else has anything better to offer, then perhaps you should find a VB specific game forum (since it appears that''s what you are using). I remember a few years back there were several sites out there related to using GDI in VB for games.

Good luck.

Share on other sites
quote:
Original post by Aldacron
You do not need to do use DX 8 if you have the DX 8 SDK. You can still use DirectDraw 7.

As far as the backbuffers go, option 1 which I suggested is much more efficient than option 2 in DDraw. For GDI, I haven''t a clue. I haven''t touched GDI in years.

I respect the fact that you like to do things yourself. I''m the same way And you can make some nifty games with pure GDI, but you mentioned yourself that ''GDI starts to slow down'' after 5 good sized bitmaps are loaded. This is exactly the issue DDraw was originally created to address. Sorry I can''t help you more. If no one else has anything better to offer, then perhaps you should find a VB specific game forum (since it appears that''s what you are using). I remember a few years back there were several sites out there related to using GDI in VB for games.

Good luck.

well the original engine was in vb, but now its in C++ and still using the GDI. I dont even plan on attempting direct x in C++, it wasnt SO bad in VB, but its probably HORRIBLE in C, with all the complicated data types (in vb, all gdi objects are just longs)

--Fireking

Genetics 3rd Dimension Development