Archived

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

2d engine design philosophy

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
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 this post


Link to post
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

Owner/Leader
Genetics 3rd Dimension Development

Share this post


Link to post
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

Owner/Leader
Genetics 3rd Dimension Development

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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

Owner/Leader
Genetics 3rd Dimension Development

Share this post


Link to post
Share on other sites
Speed without the the DX syntax? OpenGL is for you.

Personally; I always use OpenGL, unless I''m using the ''utlity'' parts of DX (like dsound), then it makes more sense just to use direct3d too.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Consider using Allegro. Relatively speedy, easy to use, and relatively portable.

www.talula.demon.co.uk/allegro/

Share this post


Link to post
Share on other sites
DX in C isn''t that horrible, but I can appreciate your fondness for GDI. In fact, I''d be interested in checking out your code if you''re up for sharing it, fireking. Drop me an email if so.

Share this post


Link to post
Share on other sites
Whats up FireKingX,? still playing around with the GDI I see.
Drop by Truevision and ruffle those rats up a bit, everyone has grown complacent without you messing around with them a bit. Ever finish the editor that you built that great GUI for?


Dreddnafious Maelstrom

"If i saw farther, it was because I stood on the shoulders of giants."

Sir Isaac Newton

Share this post


Link to post
Share on other sites
quote:
Original post by Dreddnafious Maelstrom
Whats up FireKingX,? still playing around with the GDI I see.
Drop by Truevision and ruffle those rats up a bit, everyone has grown complacent without you messing around with them a bit. Ever finish the editor that you built that great GUI for?


Dreddnafious Maelstrom

"If i saw farther, it was because I stood on the shoulders of giants."

Sir Isaac Newton


lol!

actually, i did not finish Gen3dEdit. Mainly due to the fact that Truevision was missing a lot of features I was needing at the time. I could resume the project eventually, but expect at least a 2 week period as I look at all of my code and understand it all again (it was an insanely complicated program, keeping all of the gui in order with the dynamic object oriented design of the world).

Yeah, Im still messing with the GDI. Kind of a self education type of deal. It''s like a new years resolution or something, a promise made to my self, that I can accomplish a 2d tile engine with the GDI in great speeds with tons of features. I am using C++ to do it now, mainly because I just need to move on, and VB is really a peice of junk (depending on the app you are making).

Good to hear from ya!

--Fireking

Owner/Leader
Genetics 3rd Dimension Development

Share this post


Link to post
Share on other sites