Theory on creating an EOB like graphical engine

E

EFileTahi-A

Well-known member
Joined
Aug 8, 2004
Messages
539
Location
Portugal / Barreiro
Do you folks remember Eye of Beholder game or even Dungeon Master?

[Broken External Image]: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, Im 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 dont 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...
 
Last edited by a moderator:
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.
 
Im 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). Players 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 dont 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 shouldnt be too difficult. Its the rendering that would be the challenge.
 
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 arent using a hardware accelerated, polygon based engine doesnt mean that they arent textures. Thats just my two cents.

And this isnt quite the same as Wolfenstein 3D. You move a whole tile at a time, and turn ninety degrees at a time. The rendering isnt 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.
 
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.
Click to expand...

No model, no texture.

And yes, your right on one point...it isnt 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.
 
Diesel said:
In computer graphics, a texture is a bitmap image used to apply a design onto the surface of a 3D computer model.
Click to expand...
Im 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
Click to expand...

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+?
 
To be completely honest, I wouldnt 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
 
Oh, no doubt that DirectX would be easier. Im 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.
 
The game from the screenshot from the opening post is like 15 years old. and its 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.

Code: 
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, Im kind in a hurry so I can explain this any better...

Later!
 
Last edited by a moderator:
The problem wont 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.
 
Take a look at the source code from the link I posted. Theres no explanation needed...the friggin code is there. Ive 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
 
Diesel said:
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
Click to expand...

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, thats why its builtin resolutions were something like 320x256, 640x512 etc...

I will not mention Overscan nor Multisync resolutions as I dont recall them exactly, yet Im 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 dont 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 youre going to say if want to correct someone elses comments with such authority.

PS: You can always download Ultimate Amiga Emulator "UAE" to learn more about Amiga computer if you want to.
 
Last edited by a moderator:
Diesel, take it easy. Regardless of whether you are (or anyone else is for that matter) right or wrong, being rude or insulting isnt 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.
 
Cags said:
(...)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.
Click to expand...

You dont have to do nothing with the pictures except loading them ;).

[Broken External Image]:http://img.photobucket.com/albums/v698/EFileTahi-A/EOB_03.jpg
[Broken External Image]:http://img.photobucket.com/albums/v698/EFileTahi-A/EOB_02.jpg
[Broken External Image]: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 dont 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. (...)
Click to expand...

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.
Click to expand...

Monkey Island was a great game ;)
 
Last edited by a moderator:

Similar threads

C
Roborock S6 MaxV robotic vacuum review: Pricey but powerful
Replies
0
Views
102
Christian de Looper
C
P
10 early Prime Day deals hidden deep on Amazon’s site
Replies
0
Views
88
Peter Martin
P
M
Philips Hue skipped Black Friday, but it’s running so many deals right now on Amazon
Replies
0
Views
96
Maren Estrada
M
E
Heirloom Software: the Past as Adventure
Replies
0
Views
449
Eric S. Raymond
E
EDN Admin
Maelstrom: An Overview
Replies
0
Views
141
EDN Admin
EDN Admin
Back
Top