Eidolon Engine for RPG?

[Gunstar]

the code itself looks not so unrolled like i thought it will so you find loops as well even in the sprite routine which i personally found interesting. i had expected that they squeezed out every cycle they could.

 

Well, this is a good thing then, since it means there is room for further optimization of the engine/code.

Edited May 28, 2007 by Gunstar

[cualquiercosa327]

hello,i know this post is 2007 but i am very interesting how eidolon engine works.I tried contact with Heaven/TQA but it doesnt allow me send pm.

I am new on atari,my machine was a cpc ,but any info is welcome.

I was searching on net and also contacted with loren carpeten with facebook.He told me he has not have the sources,but he remember ome things i would like share with you.

"The visibility/hidden line part was done with what's called a "height field algorithm". Basically you draw the scene from near to far, keeping track of the "highest" point at each horizontal screen coordinate in the picture. Then when you are to draw in a new line (or pixel) you check to see if it is higher than anything drawn before. If so, then you draw it and update the height for that screen column, otherwise you skip it. Another thing that speeds it up is that perspective is only calculated for the horizontal axis. The vertical axis is scaled by a simple distance multiplier. The high and low points in the landscape were computed from scratch when the program started. Drawing fractal lines was done with midpoint subdivision (randomly displace the midpoint up or down an amount proportional to the length of the line). Keep doing that until the lines were 1 pixel long."

 

do you found more things with your disasm code?

thanks

dani

[Heaven/TQA]

seems I have to many mails... need to clean my inbox... good to know that carpenter is on f,

[Lazarus]

Still there must have been used a technique to fill quite a large area with some colour. The Koronis Rift version of the engine even fills the more distant mountains with a different shade while RoF and Eidolon both only trace the contours of the moutains/walls (so you don't actually have to fill them up). Have you got any idea how the routine works if it's not some optimized implementation of floodfill?

I am pretty sure no 3D engine uses floodfill to fill their polygons

 

Anyway, the RoF-engine rendering only works with a height map and 1D rotation. There are a few true 3D polygon engines on 6502 computers, but they are much slower even if they only do lines. The ones with filled polygons are dead slow.

 

Just look at Advanced Flight Trainer on C64 (the A8 version would be about 30% faster).

Edited January 16, 2010 by Lazarus

[Heaven/TQA]

looks like a earlier and simpler method like the z-buffer approach but only for all x-pos... so actually a y-buffer?

[Heaven/TQA]

http://www.gameprogrammer.com/fractal.html

[oky2000]

I'm sure the A8 routines for Eidolon could be optimised more, look at the difference with the C64 (negligible) and then compare the two versions of RoF and KR. A noticeable difference in speed on those two.

[Crazyace]

Isn't the main reason that ROF is faster the fact that it only uses 47 lines ( In the 160x96 mode ) - and Eidolon uses a lot more lines ( in the 160x192 mode which matches the c64 better )

Koronis uses around 90 lines of GTIA mode 10 - which is completely different to the way the C64 works ( hence the extra shades ) so the 2 versions are less comparable.

[cualquiercosa327]

Hi,i had some interesting links about fractals on atary on the historial.here are the links:

 

http://www.atarimagazines.com/v4n12/Fractals.html

 

and

 

http://www.atarimagazines.com/v4n12/3DFractals.html

[thorfdbg]

While I cannot tell you for sure how the Eidolon works - except that it is the same engine also used for other Lucasfilms games, just "upside down", i.e. it draws a cave instead of mountains - I spend quite a while trying to understand the "Capture the Flag" engine.

 

It doesn't draw polygons for sure. The trick is that it is sufficient to draw the top (or bottom, for eidolon) edge of the mountains. In case of "Capture", all it

has to draw are the upper edges of the wall, in the right angle. Specifically, the background uses color 3, and the edges use color 0. Now, a "super fast" fill

routine fills the walls in. The idea is to use an "LDA #$ff" and "AND screenposition" "STA screenposition" loop vertically over the frame. Since the "empty" set is

in color 3, the contents there remains unfilled, but as soon as the "AND" instruction hits the upper edge of the wall, the accumulator is loaded with the color of the

edge, and stores it into the next line below. Due to the AND, the accu then simply stays like this. Since the loop is vertically, the walls are filled in downwards.

 

This fill-routine is not part of the game, but created algorithmically, i.e. by self-modifying code.

 

For capture, a nice display list trick also mirrors the upper part of the screen to the lower part, efficiently dividing the effort by two.

 

For the Lucasfilms games, I think, they use a similar loop except that they first compute the start position of the line, then jump into a loop that, from that point

on, fills the screen downwards (or upwards, for the eidolon).

 

The screen rendering isn't *fractal* at all. It is just drawing vertical lines one after another, where the start position of the drawing algorithm is computed from

the cave. The landscape of "Rescue on Fractalus" is derived from the fractal, but that's as much "fractal" as there is in the engine.

 

Greetings,

Thomas

[Heaven/TQA]

Thomas,

 

as far as I had looked into Eidolon it fills the screen with $FF. and the edges are "and"ed... and as there are a lot of ADC #40 in the draw loop it will be drawn vertically...

 

but what is "fractal" is the midline displacement mentioned...

[Rybags]

I watched a good doco on Fractals not long ago.

 

The simple explanation is that you can create artifical mountains by just taking triangular slices out. The more slices, the more realistic your mountain looks.

 

If the rendering system is that simple - maybe it have some real benefit by being VBXE blit-accelerated.

[Lazarus]

The screen rendering isn't *fractal* at all. It is just drawing vertical lines one after another, where the start position of the drawing algorithm is computed from

the cave. The landscape of "Rescue on Fractalus" is derived from the fractal, but that's as much "fractal" as there is in the engine.

The landscape isn't fractal. It's just a simple heightmap. The line-drawing routine is just modified that it adds fractal offsets to the y-positions of each dot painted. Other than that it's just heightmap + lines which connect the neighbouring heightmap positions.