Eidolon Engine for RPG?

[Heaven/TQA]

i just watched the c64 longplay and realised that the 3d engine might be very stylish for a RPG? its fast looks, has dungeon style, you can turn around?

the fightings could be done turbbased but walking could be very cool.

 

any ideas how they have done it fast?

[Gunstar]

What is c64 longplay? But if you are refering to the Lucasfilm ATARI 8-BIT engine of Eidelon, yes, it would work FANTASTICALLY for an RPG and even a DOOM-like FPS! It is full 360 degree freedom of movement with a very decent framrate considering...any of the Lucasfilm Atari engines would be wonderful for other games, like Rescue on Fractalus or Koronis Rift engines would make good outdoor settings for RPG's or FPS's too. They are all 360 degrees of free movement, and Rescue on Fractalus has altitude/up&down, and I think Koronis Rift too, since you go up and down when returning to the ship/rifts. The question is if any of these game engines have the source-code available.

[Heaven/TQA]

yo. thats what i ment... you could use them. the only bits and pieces you can find on the net are from rescue on fractalus, eidolon is a "up side down" derivate from rescue engine as stated in an interview. eidolon in dungeons, koronis "outside" and rescue engine for having your "epic lv70 mount"...

 

would be interesting to decompilate such an engine but will be hard imho.

[Heaven/TQA]

and as there are several conversions of the game (same goes to koronis rift) maybe its easier to get some info how it is done... is there an apple 2 port as well? as the msx,spectrum,cpc ones are all z-80 based.

[pseudografx]

That would really be something to implement the Lucasfilm engine into an RPG. IMHO the principle of the engine is drawing a polygon as a floor (or sky) and then add some lines as contours of the shapes (ie. walls in the caves or slopes in the mountains). I think the slowest part is drawing the filled polygon. Once you have the scenery, you can add enemies as software sprites (I'd suggest colouring them with underlay PMG).

This procedure will also take quite a lot of CPU time, especially if you want to draw several enemies in one scene. You can save some CPU time with using narrow playfield (which would still keep the viewport big enough). Not only will you save a few CPU cycles per every scanline, but the area to be filled will be reduced. Also the drawing routines may benefit from the multiples of 32 bytes per line.

[Rybags]

Let's not forget here that the Alternate Reality engine was (supposedly) capable of rendering at any angle and not just the 90 degree increments as implemented in the game itself.

 

An Eidelon based RPG would be a good idea, but I get the feeling that it would really grind once onscreen objects were added.

 

But, RPGs don't generally rely on lightning smooth/fast graphics, so it could be something that people would live with.

[Gunstar]

That would really be something to implement the Lucasfilm engine into an RPG. IMHO the principle of the engine is drawing a polygon as a floor (or sky) and then add some lines as contours of the shapes (ie. walls in the caves or slopes in the mountains). I think the slowest part is drawing the filled polygon. Once you have the scenery, you can add enemies as software sprites (I'd suggest colouring them with underlay PMG).

This procedure will also take quite a lot of CPU time, especially if you want to draw several enemies in one scene. You can save some CPU time with using narrow playfield (which would still keep the viewport big enough). Not only will you save a few CPU cycles per every scanline, but the area to be filled will be reduced. Also the drawing routines may benefit from the multiples of 32 bytes per line.

 

It has absolutely NOTHING to do with polygons (Lucasfilm A8 engine(s)), they are done with FRACTAL technology engines.

[pseudografx]

That would really be something to implement the Lucasfilm engine into an RPG. IMHO the principle of the engine is drawing a polygon as a floor (or sky) and then add some lines as contours of the shapes (ie. walls in the caves or slopes in the mountains). I think the slowest part is drawing the filled polygon. Once you have the scenery, you can add enemies as software sprites (I'd suggest colouring them with underlay PMG).

This procedure will also take quite a lot of CPU time, especially if you want to draw several enemies in one scene. You can save some CPU time with using narrow playfield (which would still keep the viewport big enough). Not only will you save a few CPU cycles per every scanline, but the area to be filled will be reduced. Also the drawing routines may benefit from the multiples of 32 bytes per line.

 

It has absolutely NOTHING to do with polygons (Lucasfilm A8 engine(s)), they are done with FRACTAL technology engines.

Of course I may be wrong, but this is how I would try to implement it (if I was into coding 3d engines). Could be reasonably fast, perhaps even faster than the actual Lucasfilm engine.

[Heaven/TQA]

eidolon already has "monster fights" so you can have static pic like in AR when encounter a monster. and look what they have done in their animation engine... so definitly Eidolon is the way to go... but depends of course how many ram is left as i experienced how many ram you need for tables & texts & stats etc which are needed for a RPG

[dwhyte]

but depends of course how many ram is left as i experienced how many ram you need for tables & texts & stats etc which are needed for a RPG

 

agreed...

[pseudografx]

eidolon already has "monster fights" so you can have static pic like in AR when encounter a monster. and look what they have done in their animation engine... so definitly Eidolon is the way to go... but depends of course how many ram is left as i experienced how many ram you need for tables & texts & stats etc which are needed for a RPG

It's not that hard - you just have to come up with a solution that is optimized both in performance and small footprint

[Heaven/TQA]

ok... started to have a look into the code...

 

- display list is simple antic e so 40 bytes per scanline

- vram $4600

- ram below $c000-$ffff is used and you find debug text there (their cell animation)

- code starts at $6a00

[Heaven/TQA]

- vram2 at $3100 for double buffering

- joystick routines at $9f05

- $cd94,$cd95,$cd96,$cd97 could be the inc adresses for the xpos,ypos

[Wrathchild]

In looking at this game when porting it to cart but I didn't delve into the

graphics engine. The loading of a level was interesting though as they use

their own file system (on top of their own I/O routines for copy protection

and allowing music to be played whilst loading). Within this the levels files

declared what monsters were required for that level and those were

loaded up before the level started. Quite an elegant solution, and one that

I think would certainly be useful to use within a cart game, it gives you a

fallback to simply ask for a data file by filename. Utilities in your rom image

build process can layout the ROMFS, I was thinking along those lines when

looking at 'World Class Leaderboard' as the course and hole data is available

directly from the C64 disks as files. Maybe I can expand upon the demo

I made and send you an example of doing this (in ca65/ld65 of course )

 

Regards,

Mark

[Heaven/TQA]

-$6cde CLR VRAM1 ($3100) simply type A $6ce0 plus LDA #$11 f.e.

-$6d27 CLR VRAM2 ($6200)

- $7972 writes 2nd half of screen, change AND #3 into AND #1 f.e.

- $64 seems something to do with the blinking of the cave, change $798c from EOR $64 into AND $64

[Heaven/TQA]

- the display list seems to be build every frame as when you change the dlist f.e. at $6333 it will be overwritten

- $79ff is the random blinking routine for the cave, f.e. change $79aa from ORA #4 into ORA #1 and you see the pixels jumping along the lines.

- $949b and $94ab are mask tables for pixels

- $82f8 ff are the "write line into vram routine" streight brute force copy

- $82bb --> $e8/$e9 pointer into vram --> routine writes the bottom edge of the cave. interesting that it writes the line not per scanline but moves the pointer along the edge... (hint --> SBC #$28 = 40 bytes --> see dlist antic e)

[Heaven/TQA]

- $8800 ff is the dragon copy routine --> $e3/$e4 pointer into vram (hint ADC #$28 --> change f.e. to #$20)

where the hell is the cave draw routine...

[Heaven/TQA]

- $b3xx is handling the panel gfx ($c000)

[Gunstar]

That would really be something to implement the Lucasfilm engine into an RPG. IMHO the principle of the engine is drawing a polygon as a floor (or sky) and then add some lines as contours of the shapes (ie. walls in the caves or slopes in the mountains). I think the slowest part is drawing the filled polygon. Once you have the scenery, you can add enemies as software sprites (I'd suggest colouring them with underlay PMG).

This procedure will also take quite a lot of CPU time, especially if you want to draw several enemies in one scene. You can save some CPU time with using narrow playfield (which would still keep the viewport big enough). Not only will you save a few CPU cycles per every scanline, but the area to be filled will be reduced. Also the drawing routines may benefit from the multiples of 32 bytes per line.

 

I see, but Lucasfilm didn't use any polygons even for the floor/ceiling/sky, etc., I think it's really something that just isn't needed and would take up too much unneccesary processing power, especially in a 1.79Mhz 8-bit processor that was never designed to do polygons. You are thinking with too modern of a mindset. You just need the fractal engine, and then pretty much "empty space" with background colors as was done by Lucasfilm. Fractal and sprite (player/missle) graphics is all that's needed, like Lucasfilm used. And by today's standards the Lucasfilm games are already slow enough frame-rate wise, you certainly don't need to take up more processing power for even one polygon for the "floor." You could just do a fractal engine which would be "upside-down" like in the Eidelon for interior environments and then "rightside up" like Koronis Rift or ROF for exterior environments. The Eidelon already has use of multiple "sprites" or software sprites or what ever they used for the characters and power orbs in-game, there were often several on-screen at one time, and the dragaons themselves were made so large by using multiple "sprites." It's plenty fast for an RPG engine on the 8-bit, as-is, includng the "sprites" for the characters or objects.

Edited May 27, 2007 by Gunstar

[pseudografx]

I see, but Lucasfilm didn't use any polygons even for the floor/ceiling/sky, etc., I think it's really something that just isn't needed and would take up too much unneccesary processing power, especially in a 1.79Mhz 8-bit processor that was never designed to do polygons. You are thinking with too modern of a mindset. You just need the fractal engine, and then pretty much "empty space" with background colors as was done by Lucasfilm. Fractal and sprite (player/missle) graphics is all that's needed, like Lucasfilm used. And by today's standards the Lucasfilm games are already slow enough frame-rate wise, you certainly don't need to take up more processing power for even one polygon for the "floor." You could just do a fractal engine which would be "upside-down" like in the Eidelon for interior environments and then "rightside up" like Koronis Rift or ROF for exterior environments. The Eidelon already has use of multiple "sprites" or software sprites or what ever they used for the characters and power orbs in-game, there were often several on-screen at one time, and the dragaons themselves were made so large by using multiple "sprites." It's plenty fast for an RPG engine on the 8-bit, as-is, includng the "sprites" for the characters or objects.

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?

[Heaven/TQA]

as i had a quick "random look" into the code yesterday i can tell that the engine is very "oldschoolish" which means that the screen is filled by #$ff every frame and the dots are draw on top of that, same goes to the bottom edge of the cave. it uses double buffer for less flickering.

 

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.

 

its hard to reengineer a fractal engine if you have no idea how they have done it so what i am trying to find is the actuall plot routine which points to the data. from the joystick routine you can find the zeropage vars which point to the map and the player positions etc.

 

but its only the matter of time...

[Heaven/TQA]

fully agreed.

[Heaven/TQA]

playing again little bit with the code...

 

change $82bb into lda #$AA and you see that the edges are being drawn manually so it is really like gunstar said. most of the screen is untouched.

 

and before we enter the discussion why the hell they havent used pm underlays etc... most of the time lucasfilm used them clever for the panels and onscreen stuff see rescue on fractalus, koronis rift and here the orbs...

[Heaven/TQA]

ok. the random blink routine is a good starting point to mess around

 

at 7a1f you find following code

 

lda ($32),y

and $949b,x

ora $94ab,x

sta ($32),y

 

this code sets the plotted pixels "blue". so if you change f.e. the first and which does the masking with f.e. and $d20a then you see that it change the masks for all pixels on the screen. and the routine around there is drawing the screen from horizon downwards. so i have to find the routine which draws the upper part of the screen...

[Moon]

What is c64 longplay?

 

It's a complete walkthrough of a C64 game recorded as video which you can download here.