Theory on creating an EOB like graphical engine

Just a quick question: Say you simulate less than a 90 degree field of view, displaying four tiles deep, and you use a different image for each element (i.e. floor in occupied square, wall on left, wall on right, three images for the floors in the next row of tiles, and two or four walls for that row, five images for tiles in the next row, all the ceilings, etc.), that would come out to at least fourty images, no? Say you want to make it interesting and add ten or so types of walls (lets say stone, like the example image in the first post, add cave walls, cement walls, tile walls, you get the idea), that would become about four hundred different images for the walls. Do I have the right idea?

If so (and Im not sure Im right), you might want to consider something like this: First of all (and you might have already considered this part), since every tile will usually have a floor and ceiling, start rendering every screen by drawing an image that contains the floor and celinging for all the visible tiles (sample1.gif). Then you draw maybe three images for walls: those for the row of tiles extending straight forward (sample2.gif), another for the next row out (further left/right), and maybe a third. Using precalculated X coordinates from the simulated 3D projection (sample3.gif) you can cut the wall images into vertical strips for each tile (sample4.gif), drawing only certain portions with an overload from Graphics.DrawImage for the walls for different tiles. Use a similar technique for the walls that will be facing you. This would cut you down to six or seven images per texture, and produce images along the lines of sample 5. (Sorry about all the long post and five attatchments.)
 
Last edited by a moderator:
Yes Marble, you have the right ideia. If you want (for example) to add an ornamented wall you will have to render it in all visible angles. Same thing goes for the monsters you might want to add to the game, they shoud be rendered in all locations too. Alternatively, you could render the enemies using this method (which was used in EOB) resulting in less pictures by skiping redering the monster in side/angle views.

Lets say you have a skeleton warrior.

The skeleton should be rendered 1,2,3,4 and 5 blocks/cubes away in the middle of the screen to get a full straight view of them in four available directions, front, back, left side and right side. resulting in 20 pics to his graphic set (lets make 21 to include the attack picture too ;)).

And yes the floor and celling should be the first things to be drawn as I though it would be as I described in my opening post.

Say marble, youre showing much interest in this graphic engine, are you up to create something? Wanna start a party? Sometimes I kept thinking. How can be possible that there are projects made over internet by groups of ppl which are from most places of the world? I mean, I cant find no one with the will to form a group to acomplish something...
 
Last edited by a moderator:
It would be far more effective in terms of storage and design time effort to create a single tile for each type and at runtime scale / rotate it to the correct size and angle.
Rather than store the details (skeleton, torch, chains etc) on a given tile they could be created as separate images and overlayed on the tiles at runtime.
 
PlausiblyDamp said:
It would be far more effective in terms of storage and design time effort to create a single tile for each type and at runtime scale / rotate it to the correct size and angle.
Rather than store the details (skeleton, torch, chains etc) on a given tile they could be created as separate images and overlayed on the tiles at runtime.

Do you really think so? Do you think that rotating, scaling and posicionating a certain pciture would be much simpler and less time consuming then simply showing a certain picture?

Rotating... Where? Certain degrees? How many degrees exactly? Where to be drawn at x,y? How much exactly should be scaled? Do you realise of how many times I would need to run the project until I get the bug-free formula? This is definately not for my brain...

I do agree it would require less storage space by using this method but... The trabe off would be more cpu consuming...

:confused: :confused: :confused:
 
Last edited by a moderator:
If you are using an EoB style engine where everything is done as a grid with no inbetween steps and 90 degree turns then all scaling values will be fixed as will all other transformations.
Also depending on what technology you are using to draw to the screen this functionality may be provided for you.
 
Didnt we just skip backwards in the conversation here? Drawing the thousands of tiles required would certainly be time consuming, but I thought the whole point of that was to avoid the complexities of manipulating the images. Whilst its true the camera angle being fixed is a big help, drawing the oddshaped tiles still wouldnt be easy using GDI (which i got the impression is what will be used). Especially as the brightness of the textures are also altered. Whilst its true you could probably achieve this effect using GDI, it will take a pretty capable programmer to achieve a decent effect.
 
If we are using DirectX, there is no problem using a single texture. On the other hand, GDI+ can scale, skew, and rotate images. It can not perform the distortions necessary to create the effect of a perspective. Besides, doing it the pre-rendered way is old school, and cool, and stuff. Its got more EOB spirit.
 
Ok the EOB engine is on the works... I will make both GDI+ and DirectX versions...

Hopefully, I will finish the GDI+ version this weekend...
 
Last edited by a moderator:
Back
Top