Theory on creating an EOB like graphical engine

[EFileTahi-A]

Do you folks remember Eye of Beholder game or even Dungeon Master?

 

http://img.photobucket.com/albums/v698/EFileTahi-A/1052220900-00.gif

 

If you know/played any of these games then you will also know that when we move in any of the four available directions the player moves by gaps (blocks) instead of a smooth animation.

 

Well, I'm wondering how does such grahical engine works. I mean, I know we need a 2D map like a crossword board representing the dugeon maze, but, how to assemble the graphics representing the maze? Do we have a full image per map block? (I don't think so). Or do we have some sort of formula to render the right piece of graphic? Like:

 

Render the floor;

Render the celling;

Render the left wall 1 block away;

Render the left wall 2 block away;

Render the left wall 3 block away;

Render the left wall 4 block away; etc...

 

Render the right wall 1 block away;

Render the right wall 2 block away;

Render the right wall 3 block away;

Render the right wall 4 block away; etc...

 

... I really need theoric lessons on the method used for such graphical engines...

Edited January 11, 2006 by EFileTahi-A

[EFileTahi-A]

If I wasn't explicit enough, please, do let me know about it, as I will gladly clearify anything.

 

Thank you.

[PlausiblyDamp]

For each grid square you would need to store the varous textures (or a reference to the texture) and for the view calculate what parts are visible from a given location and render the appropriate textures.

 

You may want to investigate the BSP algorithm as an example of how to do this, although for a very grid based system that may be more effort than you need.

[Talyrond]

Looks like OpenGL would do the job:

 

http://www.csharpopenglframework.com/

[snarfblam]

I'm not sure the idea here is to pay for a graphics engine (or wrapper for a graphics engine). Besides, there is a free managed wrapper for DirectX.

 

If you are using DirectX, you could create the entire environment, and just move the camera.

 

If you are using GDI+, as far as calculating whats visible, you would want to set a maximum draw distance (for example, the image you attatched has a draw distance of four rows of map tiles, including the occupied tile). Player's direction would have to be accounted for. You would want to draw from back to front. Depending on the emulated field of view, you will need to draw a certian number of map tiles in each row, increasing as you get further from the user. A 90 degree field of view would require that one tile be drawn for the occupied row (which would be the occupied tile), three tiles in the next row back, five in the next row back, and seven in the fourth row. I don't think that something like this would really require a game loop if programmed in GDI+.

 

Those are more like tips than a general plan for the engine, because (especially if you use GDI+) the overall engine is up to you and shouldn't be too difficult. It's the rendering that would be the challenge.

[Diesel]

What the hell? Is it me or did all you guys miss the boat?

 

Dude, Wolfenstein 3d! Same type of game...

 

It's a tile-based game...just with different bitmap images representing the tiles.

 

They're not considered textures because there is nothing to apply the image to.

 

 

Check this awesome Qbasic game out

http://www.geocities.com/qbasicarchives/zip/lith2_10.zip

[snarfblam]

Whether the walls are defined as polygons in a d3d buffer or a gdi+ destined tile-based map, they are being applied to a 3d or pseudo 3d environment. Just because we aren't using a hardware accelerated, polygon based engine doesn't mean that they aren't textures. That's just my two cents.

 

And this isn't quite the same as Wolfenstein 3D. You move a whole tile at a time, and turn ninety degrees at a time. The rendering isn't real time. The graphic result might resemble Wolfenstein 3D, but the underlying engine would be quite different.

 

And just out of curiosity, is it just me or is anyone else disappointed that there is still no implementation for a four point list to draw distorted bitmaps? It sort of limits you in terms of graphic manipulation.

[Diesel]

Wikipedia says Im right:

 

In computer graphics, a texture is a bitmap image used to apply a design onto the surface of a 3D computer model.

 

No model, no texture.

 

And yes, your right on one point...it isn't exactly the same as wolfenstein...the rendering is different, but the data rendered is the same, vis-a-vis the tile map, besides, I never said it was exactly the same.

[EFileTahi-A]

ok folks tks for the replies... I got a few ideias now :)

[snarfblam]

In computer graphics, a texture is a bitmap image used to apply a design onto the surface of a 3D computer model.

I'm sure you can put a little more effort into it than that. Are you trying to accurately describe what a texture is, or are you trying to discredit me?

 

That is a definition of a texture in terms of 3D models, specifically from their article on texture mapping (a technique of texturing a 3D model). It is taken out of context. If you read their article on Bitmap Textures then practically any raster image at all would be considered a texture.

 

The following is the Wiktionary definition of texture, in terms of graphics:

an image applied to a polygon to create the appearance of a surface

[/Quote]

 

Interpreting this loosely, we can come to the conclusion that the wall and floor rectangles defined or implied by the map data in the relevant games represent single polygons or rectangles constructed from two triangular polygons, and that the bitmaps rendered to represent said rectangles would be considered textures.

 

We can also observe that the Managed DirectX Texture class can be used to texture single polygons, if we so desire.

 

We can flap our lips all day, discussing whether or not our bitmaps are technically textures, but I think everyone can at least agree that it hardly matters or has much bearing on the graphical output or functionality of our program.

 

 

Just out of curiousity, can anyone think of a way to render something like this with GDI+?

[Nate Bross]

To be completely honest, I wouldn't even attempt this with GDI+. It would be much simpler to make the complete 3D environment, and limmit the camera movement to emulate the 'chunky' movement.

 

IMHO

[snarfblam]

Oh, no doubt that DirectX would be easier. I'm sure that the GDI+ rendering would be extremely slow and it would take plenty of work to make GDI+ to something particularly tridimensional. I was just wondering if it would even be possible.

[EFileTahi-A]

The game from the screenshot from the opening post is like 15 years old. and it's graphic engine does not use any 3D nor hardware aceleration (as we all know). Yet is was fast as hell. Ok it is 320X280 and used 64 colors but it was also running on 7MHz computer (Amiga500)

 

I managed to talk to a guy who made a similar graphic engine, and the engine goes like this:

 

You have an 3D array[,,] which holds:

[x,x,0] -what is walkable and non-walkable (the map itself) represendted by 1 and 0

[x,x,1] - Type of graphic set do be used.

 

We start by drawing both celling and ground (as I suspected this would be ;))

Then, it plays this formula to draw the respective graphics:
Check the drawing range:

#####
#####
#####
#####
#####
 P

Where "P" is the player current position and "#" represents the scanned area in front of the player.

*1.11
11.11
.....
11.11
11.11
 P

Now we know which area can be walked through. The "1" represent the walls and the "." the free path.
We start drawing the graphics by comencing by the farest block "*".

The selected block "*" is -2 and on horizontal position of -5 to vertical to the players "P" position, so we will draw the specific graphic from the selected graphic set named (forexample) m2_m5 (minus2_minus5). We loop this point untill all the range area have been scanned.

 

All pics will have the same size, meaning that they should only show the right portion of the wall and rest of them MUST be transparent.

 

Sorry, I'm kind in a hurry so I can explain this any better...

 

Later!

Edited January 17, 2006 by EFileTahi-A

[Cags]

The problem won't really be working out what to draw it will be actually drawing it. Obiviously it should be possible to code an engine without the use of DirectX or OpenGL but it will by no means be easy. Whilst EoB is an extremely simple game compared to todays standards, game development has been made much easier by the introduction of DirectX. As marble_eater says without a 3d based engine you are going to have to draw an image to the screen in an irregular shape. Todo this successfully you are going to have to manipulate the images quite significantly. Also looking at the screenshot you provided the game implements a (admittedly basic) lighting system so that the further parts are darker. As stupid as it sounds its sometimes easier to implement a modern style game than an old one, because alot of the work has been done by somebody else and you just employ their wrapper.

 

At one point I looked at attempting to make a monkey island style game, but after looking into it I decided it was too complex for my limited programming abilities.

[Diesel]

Take a look at the source code from the link I posted. There's no explanation needed...the friggin code is there. I've created a tile based game such as this..without directx, without gdi.

 

Also, Efile, get your friggin facts straight!

 

Eye of the beholder was released in 1990, and the only resolutions available on an amiga 500 were 320 x 200, 320 x 400 (using interlacing), 640 x 200, 640 x 400 (using interlacing)

 

So, if the game used 64 colors it ran at 320x200

[EFileTahi-A]

Also, Efile, get your friggin facts straight!

 

Eye of the beholder was released in 1990, and the only resolutions available on an amiga 500 were 320 x 200, 320 x 400 (using interlacing), 640 x 200, 640 x 400 (using interlacing)

 

So, if the game used 64 colors it ran at 320x200

 

Yeah I post it wrong, but you did it way worst...

 

The game was running on amiga 320x256 and not 320x280 (my bad, I only noticed my mistake when you posted yours) nor 320x200 (skiping here the 320x400, 640x200 and 640x400 you mentioned has they are franquely non-accurate) because, Amiga 500 ONLY resolutions were (PAL) 320x256, 640x256 1280x256 and interlaced resolutions of 320x512, 640x512 and 1280x512. These resolutions were always standard to all Amiga models (1000, 500, 500+, 1500, 2000, 600, 1200, 3000, 3000T, 4000, 4000T, CD32 and CDTV). And yes you could force all these resolutions to NTSC by holding both mouse buttons during amiga reboot to gain access to its startup menu (but only for Amigas using kickstart v2.0 and above though, plain A500 did not had this ability, so no NTSC for it). Amiga was designed to be connected directly to a TV, that's why its builtin resolutions were something like 320x256, 640x512 etc...

 

I will not mention Overscan nor Multisync resolutions as I don't recall them exactly, yet I'm not in mood to go to the bassment to reconnect my old 1200Tower with a PPCe+210mhz, 68060 50Mhz (dual CPU) plus Bvision 8MB video (Bvision recreated any VGA resolution (up to 2048x2048 by the way) so you could use any VGA monitor to plug the amiga in) ram plus 64MB of Fast Ram, Fast SCSI-II Device..., bla, bla, bla, just to post such info.

 

Another thing about this phrase of yours:

"So, if the game used 64 colors it ran at 320x200"

 

I really don't understand this conclusion of yours. Why 64 colors have anything to do with 320x256? 64 colors where available on A500 in any resolution I meantioned above, AS LONG, you had at least 1MB of memory which was a TRULY common thing among A500 users. 98% of all existing amiga games are in 320x256 (which are a few thousands).

 

Trying to lecture me on Amiga systems is definately not a "great" ideia.

Hey, we all make mistakes... ;)

 

"Also, Efile, get your friggin facts straight!" - Next time BE SURE of what you're going to say if want to correct someone else's comments with such authority.

 

PS: You can always download Ultimate Amiga Emulator "UAE" to learn more about Amiga computer if you want to.

Edited January 18, 2006 by EFileTahi-A

[snarfblam]

Diesel, take it easy. Regardless of whether you are (or anyone else is for that matter) right or wrong, being rude or insulting isn't helping anyone program anything. Good::-\ Bad::mad: See?

 

The code you posted is in QBasic, and there are 92 files. It is probably not exactly trivial to a .Net programmer. It would be more than helpful if you would clearly explain what about the rendering engine you would like us to understand.

[EFileTahi-A]

(...)As marble_eater says without a 3d based engine you are going to have to draw an image to the screen in an irregular shape. Todo this successfully you are going to have to manipulate the images quite significantly.

 

You don't have to do nothing with the pictures except loading them ;).

 

http://img.photobucket.com/albums/v698/EFileTahi-A/EOB_03.jpg

http://img.photobucket.com/albums/v698/EFileTahi-A/EOB_02.jpg

http://img.photobucket.com/albums/v698/EFileTahi-A/EOB_01.jpg

 

It is all about showing the correct pictures. The blue area will be of course transparent, leaving only the right piece of graphic to be seen/used. You also don't need to reposicionate them as they will be already in the right place.

 

You can build all the graphics using a 3D raytracing software like 3D studio or Cinema 4D. You simple create a few cubs in a row like 5 by 5 (depending of the visible range you want in the game) pattern and render each cube at the time using the same camera.

 

Also looking at the screenshot you provided the game implements a (admittedly basic) lighting system so that the further parts are darker. (...)

 

There is no lighting system at all, those are only images...

 

At one point I looked at attempting to make a monkey island style game, but after looking into it I decided it was too complex for my limited programming abilities.

 

Monkey Island was a great game ;)

Edited January 18, 2006 by EFileTahi-A

[Cags]

Oh, I see. You simply create a large amount of textures to illiminate the need to manipulate textures. Fair enough.

[EFileTahi-A]

Oh' date=' I see. You simply create a large amount of textures to illiminate the need to manipulate textures. Fair enough.[/quote']

 

Exactly! So, when will we start to create such game? ;)

[snarfblam]

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 (let's 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 I'm not sure I'm 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.)

Edited January 18, 2006 by snarfblam

[Cags]

Yes marble_eater thats the right idea (or more to the point thats the what I believe to be the right idea).

[EFileTahi-A]

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, you're 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 can't find no one with the will to form a group to acomplish something...

Edited January 19, 2006 by EFileTahi-A

[PlausiblyDamp]

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.

[EFileTahi-A]

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:

Edited January 19, 2006 by EFileTahi-A