Fröhn Posted January 24, 2006 Share Posted January 24, 2006 welcome on board... good to see more and more 6502 coders esp. c64 guys.... TMR, Sack, Fröhn, You... so people who know the evil opponent... The evil opponent starts with "S" Quote Link to comment Share on other sites More sharing options...
emkay Posted January 24, 2006 Share Posted January 24, 2006 There's only gravity, friction, collisions and ball-spin in the c64 version. No predefined paths or anything. It's all really 100% calculated realtime. 1005777[/snapback] It seems, the recognization of a predefined way is caused by the coarse calculation and used resolution. On the PC you can use 80bit FPI (if you want) on 8 bit and "simple" 16 bit computers, you have to stick with simple math-functions. Quote Link to comment Share on other sites More sharing options...
WVL Posted January 24, 2006 Share Posted January 24, 2006 There's only gravity, friction, collisions and ball-spin in the c64 version. No predefined paths or anything. It's all really 100% calculated realtime. 1005777[/snapback] It seems, the recognization of a predefined way is caused by the coarse calculation and used resolution. On the PC you can use 80bit FPI (if you want) on 8 bit and "simple" 16 bit computers, you have to stick with simple math-functions. 1005783[/snapback] position and speed resolution on the c64 version is accurate down to 1/65536th of a pixel .. all data is 32 bits! Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 24, 2006 Share Posted January 24, 2006 32 bit maths? huj... Quote Link to comment Share on other sites More sharing options...
emkay Posted January 24, 2006 Share Posted January 24, 2006 (edited) Grab the latest beta here: http://www.interstyles.nl/pd.d64 There are two tables (each in individual file on the disk image). The IGNITION table was much easier to adjust for Atari, but the other one should also be possible. 1005774[/snapback] Thanks. I think, with a clever DLI usage and Charmode, the desks will look great on the A8 aswell. Perhaps "we" shouldn't use simple char-inversion... When using a charset for 3 charmode lines, we have always 8 chars left to quick insert/exchange them if needed... Edited January 24, 2006 by emkay Quote Link to comment Share on other sites More sharing options...
emkay Posted January 24, 2006 Share Posted January 24, 2006 position and speed resolution on the c64 version is accurate down to 1/65536th of a pixel .. all data is 32 bits! 1005784[/snapback] Now it gets really interesting... For this you have to handle four bytes for calculations which means quadruple cpu speed usage.... Erm... you know, the ATARI is nearly as twice as fast than the standard c64? Now I'm pretty shure, the Atari can do this game aswell . Quote Link to comment Share on other sites More sharing options...
Fröhn Posted January 24, 2006 Share Posted January 24, 2006 Erm... you know, the ATARI is nearly as twice as fast than the standard c64? Porting the maths is a no-issue. The Problem is to do the best conversion of the graphics, that requires some good ideas. I would do 5 color charmode with an irq every 8th line so you can change colors. The lights of the flipper could be pre-rendered modifications of the graphics, so you simply exchange a few chars if a light state changes. Quote Link to comment Share on other sites More sharing options...
emkay Posted January 24, 2006 Share Posted January 24, 2006 Erm... you know, the ATARI is nearly as twice as fast than the standard c64? Porting the maths is a no-issue. The Problem is to do the best conversion of the graphics, that requires some good ideas. I would do 5 color charmode with an irq every 8th line so you can change colors. The lights of the flipper could be pre-rendered modifications of the graphics, so you simply exchange a few chars if a light state changes. 1005793[/snapback] That is the way.... Btw.... The scoreboard really would be the simplest .... Just using several double line mode (Antic 11 or 13) interleaved with a double "no DMA" line ... and you have a "hardware scoreboard" Having more CPU cycles left and the possibily of reducing memory usage, it must be possible to add some midline changes for 8-16 visual scanlines... The C64 version seems to use 166 scanlines for showing the table. Which reduces the expenditure for the "enhancement" range on the ATARI, too. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 24, 2006 Share Posted January 24, 2006 WVL how many rasterlines do the maths engine need? including mask checking etc? scrolling? Quote Link to comment Share on other sites More sharing options...
WVL Posted January 24, 2006 Share Posted January 24, 2006 (edited) WVL how many rasterlines do the maths engine need? including mask checking etc? scrolling? 1005801[/snapback] it depends a lot on the speed of the ball and the number of collisions.. Right now the ball can travel at 28 pixels/frame plus a collision/frame without exceding cpu power.. If the ball moves slow, and hits nothing, it doesnt use that much cpu power at all.. maybe 32 rasterlines. When moving fast, it eats almost all the available rastertime. Also, keep in mind the ball can collide multiple times per frame, the max I have seen while play-testing is 3 collisions/frame. Scrolling doesnt take much time at all, it basically comes for free. (I only have to update the $d800 colors, so scrolling 8 pixels requires me to copy 40 bytes of colors) Mask checking for the ball takes about 20 rasterlines (iirc, maybe a tad more).. that calculates 3 new sprites each frame (for the 3 hires colors)... then memory use.. the masking-data is not that big at all, i think it's around $800 bytes for 2 layers in the nightmare table. collision data eats a lot more, almost $3800 bytes or so for the 2 nightmare layers, part of which (around $600) I managed to stuff into the graphics themselves. background gfx also eat a lot of memory, roughly $5f00 bytes! then there's flipper animations, which take $700 bytes right now.. (this gives 7 animation frames for both the left and right flipper. I want to increase this to 13 frames later, so memory use will increase to $d00 bytes) and collision data for the flippers, also a couple of pages... then there's a gravity map (gravity can point to different directions on the table, depending on the local inclination), about $100 bytes.. music ($d00 bytes right now, will probably grow $800 bytes when finished) etc etc.. all in all the memory is pretty filled up. My best guess when all is finished, is that the game will use ALL of the c64's 64K's of memory (right now I'm using about $e800 bytes) Edited January 24, 2006 by WVL Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 24, 2006 Share Posted January 24, 2006 huj...quite a lot... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 24, 2006 Share Posted January 24, 2006 scrolling is done via the weird raster vic tricks? or what do you mean comes for free? Quote Link to comment Share on other sites More sharing options...
WVL Posted January 24, 2006 Share Posted January 24, 2006 scrolling is done via the weird raster vic tricks? or what do you mean comes for free? 1005816[/snapback] that's what i mean.. and the rasters where the tricks are done are also used to generate the display, so basically it comes for free.. (without needing the rasters for the display, scrolling would eat 25 rasters..) Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 24, 2006 Share Posted January 24, 2006 An Atari conversion would be fairly straight forward provided the source code is neat and documented. An Atari running in multi-color text mode (or GR. 0) runs about 40% faster net speed over the C-64. The fact that colour memory scrolling isn't needed, plus the fact that vertical scrolling can be done in BASIC thanks to the versatility of Display Lists means lots of cycles are free, which can be devoted to "harder" tasks like rendering a ball using multiple players (as opposed to just having to overlay a few sprites), and DLIs for colour-changing. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 24, 2006 Share Posted January 24, 2006 don't underestimate "simple" c64 tasks (i just ported Venus Express which really was streight forward code but it took longer than expected...) i guess WVL uses several special tricks which could be hard to port over... what if the game logic is depending on f.e. 256 char fonts or other special stuff? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 24, 2006 Share Posted January 24, 2006 and i guess at the end of the day it will be a RAM issue on atari as you need more aditional stuff for the atari specific overhead...like DLI code, pm underlays+code, special music driver... etc etc etc... and on atari you even don't get the scrolling for free... Quote Link to comment Share on other sites More sharing options...
Fröhn Posted January 24, 2006 Share Posted January 24, 2006 The fact that colour memory scrolling isn't needed, plus the fact that vertical scrolling can be done in BASIC thanks to the versatility of Display Lists means lots of cycles are free, which can be devoted to "harder" tasks like rendering a ball using multiple players (as opposed to just having to overlay a few sprites), and DLIs for colour-changing. The C64 versions also has to render 3 different sprites because they need to be clipped against the background. Also on A8 you'll need a number of DLIs for color changes (I guess nobody wants 4 or 5 color gfx). Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 24, 2006 Share Posted January 24, 2006 How do you get "scrolling for free" on the C-64? Character modes start on a 1K boundary and there's no trick I know of to do otherwise. Another thing: The ball is hires, therefore 16 pixels becomes 8 pixels in PMGs. If memory permitted, some sort of animation could compensate for the lower resolution to make it look better. 128 characters could definately be an issue if the program logic depends on character values. I still reckon the Atari easily has the speed to render PMGs and execute DLIs and run faster. Plus, it could display a much larger portion of the playfield as well. Quote Link to comment Share on other sites More sharing options...
Fröhn Posted January 24, 2006 Share Posted January 24, 2006 How do you get "scrolling for free" on the C-64? Character modes start on a 1K boundary and there's no trick I know of to do otherwise. There are tricks to add values of 1-40 to the display pointer (multiplied by 8 for bitmaps). Combined with the softscroll registers you can scroll any kind of bitmap or character screen without much CPU cycles wasted. You only have to render the new edges of the graphics and colors. Quote Link to comment Share on other sites More sharing options...
pseudografx Posted January 24, 2006 Author Share Posted January 24, 2006 and i guess at the end of the day it will be a RAM issue on atari as you need more aditional stuff for the atari specific overhead...like DLI code, pm underlays+code, special music driver... etc etc etc... and on atari you even don't get the scrolling for free... 1005821[/snapback] Well, scrolling the screen alone wouldn't be much difficult, but you must also count with 'scrolling' the DLIs when the table moves. And there will easily be about 20 DLIs on the screen (about 6 DLIs for the font change, plus more for changing color registers, plus more for changing underlay PMG positions) - perhaps this DLI shifting won't take that much CPU time (I'm not a skilled coder), but the next thing will: you have to scroll the contents of the sprites in software, as Atari doesn't have hardware registers for vertical sprite position. This may be over 300 bytes everytime the screen moves. Quote Link to comment Share on other sites More sharing options...
emkay Posted January 24, 2006 Share Posted January 24, 2006 (edited) and i guess at the end of the day it will be a RAM issue on atari as you need more aditional stuff for the atari specific overhead...like DLI code, pm underlays+code, special music driver... etc etc etc... and on atari you even don't get the scrolling for free... 1005821[/snapback] Vertical scrolling on the A8 is very hard.... just set a scrol bit to the charmode, set scrol in one register and the whole screen is moved... If I remember correctly, the dlis are moving with the first line of a scrolled charmode.... If not, we still can use the "no dma" lines for simulating a scrolling, as we can use them to save memory and cpu time... For saving memory, I remember using one DLI code with inc/dec storing. And, don't tell anyone that DLI's are somehow problematic ... exept the register saving. A DLI every third charmodeline would be necessary.... for the visual range... In this DLI, the charset and some colours can be changed (perhaps 2 colours mostly).... for this games it needs the huge amount of 6 DLI's for the visual desk range. Edited January 24, 2006 by emkay Quote Link to comment Share on other sites More sharing options...
pseudografx Posted January 24, 2006 Author Share Posted January 24, 2006 (edited) and i guess at the end of the day it will be a RAM issue on atari as you need more aditional stuff for the atari specific overhead...like DLI code, pm underlays+code, special music driver... etc etc etc... and on atari you even don't get the scrolling for free... 1005821[/snapback] Vertical scrolling on the A8 is very hard.... just set a scrol bit to the charmode, set scrol in one register and the whole screen is moved... I I remember correctly, the dlis are moving with the fist line of a scrolled charmode.... If not, we still can use the "no dma" lines for simulating a scrolling, as we can use them to save memory and cpu time... For saving memory, I remember using one DLI code with inc/dec storing. And, don't tell anyone that DLI's are somehow problematic ... exept the register saving. A DLI every third scanline would be necessary.... for the visual range... In this DLI, the charset and some colours can be changed (perhaps 2 colours mostly).... for this games it needs the huge amount of 6 DLI's for the visual desk range. 1005830[/snapback] you forgot about the DLIs needed for setting positions of the underlay sprites (see for example those green indicators in the top right area of the table). Edited January 24, 2006 by pseudografx Quote Link to comment Share on other sites More sharing options...
emkay Posted January 24, 2006 Share Posted January 24, 2006 you forgot about the DLIs needed for setting positions of the underlay sprites (see for example those green indicators in the top right area of the table). 1005833[/snapback] When using the PM for the Ball(s) it doesn't make sense to use PM for underlay. Exept, you keep the missiles off and use them with the shape registers in the dli's... They will automatically be adjusted to the screen then. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 24, 2006 Share Posted January 24, 2006 I'd be interested if anyone could point me to the C-64 "free scrolling" trick. As emkay pointed out, vertical scrolling is easy on the Atari. It's only really with hscrolling that things get trickier. A good old trick with PMGs is to just initialize the whole area to zeros at the game start, then render each PMG starting several bytes before the sprite and ending several bytes after the bottom of it (have the sprite definitions padded either end with zeros). But, it only works if there aren't significant vertical position changes each frame. DLIs are adjusted for you automatically with VSCROL enabled, unlike the C-64 where you have to adjust your raster IRQs according to the fine-scrolling value. Quote Link to comment Share on other sites More sharing options...
WVL Posted January 24, 2006 Share Posted January 24, 2006 (edited) I'd be interested if anyone could point me to the C-64 "free scrolling" trick. http://www.minet.uni-jena.de/~andreasg/c64...c_article_1.htm and check out 'linecrunch' and 'dma-delay' http://www.minet.uni-jena.de/~andreasg/c64...3.14.htm#3.14.4. http://www.minet.uni-jena.de/~andreasg/c64...3.14.htm#3.14.6. "By crunching whole text lines to one raster line each you have the possibility to quickly scroll the screen contents up by large distances without moving bytes in the graphics memory, in a similar way as you can scroll it down with FLD. The only disturbing side effect is that the crunched lines pile up at the upper screen border, looking awkward. But here you can use one of the invalid graphics modes to blank out these lines." that's why the displayed screen is only 167 lines high.. Normal c64 screen is 200 high - 8 for softscroll - 25 for max 25 lines of linecrunching. Edited January 24, 2006 by WVL Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.