Heaven/TQA Posted May 26, 2007 Share Posted May 26, 2007 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? Quote Link to comment Share on other sites More sharing options...
Gunstar Posted May 26, 2007 Share Posted May 26, 2007 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. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 27, 2007 Author Share Posted May 27, 2007 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. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 27, 2007 Author Share Posted May 27, 2007 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. Quote Link to comment Share on other sites More sharing options...
pseudografx Posted May 27, 2007 Share Posted May 27, 2007 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 27, 2007 Share Posted May 27, 2007 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. Quote Link to comment Share on other sites More sharing options...
Gunstar Posted May 27, 2007 Share Posted May 27, 2007 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. Quote Link to comment Share on other sites More sharing options...
pseudografx Posted May 27, 2007 Share Posted May 27, 2007 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. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 27, 2007 Author Share Posted May 27, 2007 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 Quote Link to comment Share on other sites More sharing options...
dwhyte Posted May 27, 2007 Share Posted May 27, 2007 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... Quote Link to comment Share on other sites More sharing options...
pseudografx Posted May 27, 2007 Share Posted May 27, 2007 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 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 27, 2007 Author Share Posted May 27, 2007 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 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 27, 2007 Author Share Posted May 27, 2007 - vram2 at $3100 for double buffering - joystick routines at $9f05 - $cd94,$cd95,$cd96,$cd97 could be the inc adresses for the xpos,ypos 1 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted May 27, 2007 Share Posted May 27, 2007 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 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 27, 2007 Author Share Posted May 27, 2007 -$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 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 27, 2007 Author Share Posted May 27, 2007 - 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) Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 27, 2007 Author Share Posted May 27, 2007 - $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... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 27, 2007 Author Share Posted May 27, 2007 - $b3xx is handling the panel gfx ($c000) Quote Link to comment Share on other sites More sharing options...
Gunstar Posted May 27, 2007 Share Posted May 27, 2007 (edited) 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 Quote Link to comment Share on other sites More sharing options...
pseudografx Posted May 27, 2007 Share Posted May 27, 2007 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? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 28, 2007 Author Share Posted May 28, 2007 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... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 28, 2007 Author Share Posted May 28, 2007 fully agreed. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 28, 2007 Author Share Posted May 28, 2007 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... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 28, 2007 Author Share Posted May 28, 2007 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... Quote Link to comment Share on other sites More sharing options...
Moon Posted May 28, 2007 Share Posted May 28, 2007 What is c64 longplay? It's a complete walkthrough of a C64 game recorded as video which you can download here. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.