Thomas Jentzsch Posted January 9, 2013 Share Posted January 9, 2013 We're still getting rock-solid framerates... Not exactly. The physical frame rate is constant (but that's true for all consoles), but the logical frame rate is not. E.g. a lot of old games update several things only every 2nd or 4th frame. Something you will hardly notice. Some modern home brews (Boulder Dash, my Elite Demo, Star Castle...) go further. They implement a scheduling mechanism. So when a game is really busy, the logical frame rate may drop down quite a bit (e.g. 10 Hz). This you may notice, depending on how it is done. 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 9, 2013 Share Posted January 9, 2013 (edited) Indeed these 'innovations' give satisfaction. 100% agreed. Working within the given limitations and still finding a very good compromise is always very satisfying for me too. Edited January 9, 2013 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
roland p Posted January 13, 2013 Share Posted January 13, 2013 (edited) Ok, things todo: 1. Make kernel bug-free. Masking of rotofoil and goalbeams aren't implemented in every kernel yet (checkerboard has 37 kernels...) 2. Dumb down gamelogic. It uses 24bit values for speed and position. I could use 16bit for position. Maybe I can get away with 8bit for speed? 3. Stick with 4-frame sequence for frame 1.gamelogic, 2,3,4 for (pseudo) 3d to 2d calculations. I hope this gives enough spare cycles. 4. Try to maintain 60fps screenupdate by using vectors. These vectors are now represented in 16-bit having 256.256 presision. Maybe I could use 8-bit values and 64.4 precision. Objects will move max 64 pixels and will have fine-grained movement too. The .8 is exactly enough since the vectors are calculated by pos2-pos1 and LSR'd twice (divided by 4, since the vector is used in frame 1,2,3,4). Or store pos2-pos1 and LSR twice every frame, just before adding them to the 2d positions. 5. Checkerboard colors are stored in 48 bytes, 2bytes/line. This could be trimmed down to 24 bytes since the 'other' color can be derived from a table. LDX COLOR_LINE1 LDY GET_OTHER_COLOR,X Edited January 13, 2013 by roland p Quote Link to comment Share on other sites More sharing options...
roland p Posted January 22, 2013 Share Posted January 22, 2013 (edited) Last weekend I've dumbed down the gamelogic. The memory usage for the rotofoils position/speed was like: p1_pos_x: 3 bytes p1_speed_x: 3 bytes p1_pos_y: 3 bytes p1_speed_y: 3 bytes And the same for p2. It's now like this: p1_pos_x: 2 bytes p1_speed_x: 1 bytes p1_pos_y: 2 bytes p1_speed_y: 1 bytes (maybe I should change y into z...) So the game logic has less bytes to deal with and is now faster/easier/smaller (the routine for moving/deceleration/bouncing against boundary is now about 140 bytes ) And the gameplay isn't much different. The deceleration is now done with LDA p1_speed_x and then 3 times LSR'd. This is a huge performance gain since LSR'ing big numbers is much slower than LSR'ing just the accumulator. I even could use a look-up table here. When 3x LSR results in zero it just decrements the speed by one. I've also simplified the bouncing, so there won't be a cascade of bouncing when a rotofoil bounces at another rotofoil (inter-rotofoil bouncing is still to implement) that is close to a boundary (brown part of the playfield). I will now look again at the pseudo 2d>3d calculation to see if that can be simplified. It is now done through calculation, but I hope it can be done with some compressed look-up table. Edited January 22, 2013 by roland p 1 Quote Link to comment Share on other sites More sharing options...
+selgus Posted February 3, 2013 Share Posted February 3, 2013 Good to see you still working on this project, and I would say used whatever tools/hardware that is available that can plug into the cartridge port to make the best version you can. Quote Link to comment Share on other sites More sharing options...
roland p Posted February 4, 2013 Share Posted February 4, 2013 (edited) Good to see you still working on this project, and I would say used whatever tools/hardware that is available that can plug into the cartridge port to make the best version you can. Right now I'm dumbifying my code as much as possible to see if an acceptable version is possible. For calculating the x2d position I want to precalculate all values and put them in tables. Basically I want to create 2 tables, one for coarse positioning, and one for fine positioning. The coarse positioning will be addressed with the high byte of the X3d value, the fine positioning table will be addressed with the low byte of the x3d value. To minimize the tables I want to use for coarse positioning, only the lower nibble (If something is >16 away, it wont be displayed anyway), for fine positioning I want to use the high nibble of the lower byte of the x3d value. I want to store X2d positions for each scanline (footer of the rotofoil). There are about 30 scanlines (including the ones behind the horizon) where rotofoils can be displayed. Let's say 32 scanlines. So I would need 32(scanlines)x16(>X2d lower nibble) + 32(scanlines)x16(<X2d higher nibble) = 1024 bytes. To visualize, the effect will be that, when a rotofoil moves one tile to the right, it will pass through 16 x2d positions. On a scanline where the tile is excactly 80 colorclocks wide, the rotofoil will be moving 5 pixels at a time. The movement will be finer if a rotofoil is further away. Maybe I can make the movement finer by using more tables, maybe I can use different strategies for distant/close rotofoils (jump table based on >Z3d position?), but first I have to make it work in the fast possible way, history predicts that cycles are scarse anyway... Edited February 4, 2013 by roland p 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted February 5, 2013 Share Posted February 5, 2013 Having bought the Ballblazer floppy disc for Atari 800XL (still have it) - I heard it was pirated a lot - I often run your grid kernels and smile in amazement. The music demos in this thread I run also! Ballblazer_Start_Zylon.bas.bin is wow. ballblazer_start_zylon_alt7.bas.bin 2 Quote Link to comment Share on other sites More sharing options...
+thegoldenband Posted February 5, 2013 Share Posted February 5, 2013 The music demos in this thread I run also! Ballblazer_Start_Zylon.bas.bin is wow. Thank you! I was pretty pleased when I discovered that the right pitches were (more or less) available, and got it all to lock in. Random Terrain (IIRC) did a tiny bit more polishing on the envelopes/decays of the tones, though I don't remember what the filename of his version was. 2 Quote Link to comment Share on other sites More sharing options...
roland p Posted February 5, 2013 Share Posted February 5, 2013 Yes, I really should put some music in it. You guys made some great efforts and I never used it.... (yet) Also, It would be cool to implement the 'riffology' engine from the original... Any ideas on how to implement the music in assembly? Quote Link to comment Share on other sites More sharing options...
iesposta Posted February 5, 2013 Share Posted February 5, 2013 ... Any ideas on how to implement the music in assembly? Using Visual Batari Basic, change settings so it doesn't clean up generated files. Compile the music basic program. Look in the project folder for the .asm file generated for DASM. Study the .asm to see how it is done. I am guessing timers and data running in overscan or vertical blank? If riffology can't be figured out, those 3 patterns arranged into 7 measures is enough for a 2600 game. That tune doesn't play in game, just before play and during game over. The pattern break down I like (more than the riffs which should be tried last as riffs are only done in game over). 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 5, 2013 Share Posted February 5, 2013 Having bought the Ballblazer floppy disc for Atari 800XL (still have it) - I heard it was pirated a lot - I often run your grid kernels and smile in amazement. The music demos in this thread I run also! Ballblazer_Start_Zylon.bas.bin is wow. ballblazer_start_zylon_alt7.bas.bin And here's my tweaked version of that in case you missed it: http://www.atariage....50#entry1615377 ballblazer_start_zylon_alt_2008y_11m_04d_0426t.bin 1 Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted February 5, 2013 Share Posted February 5, 2013 (edited) ...Any ideas on how to implement the music in assembly? Here's an assembly version made from Random Terrain's music tables. It uses my sound routine 'NoisePlayer', which is a very simple but small pattern player (just the two macros seen at the top of the code). I don't know how 'Riffology' works (and I'm not going to read the Langston paper ), but if the pattern table was in RAM it would be easy to change the pattern seqence algorithmically. NoisePlayerDemo.bin NoisePlayerDemo.zip Edited February 5, 2013 by Joe Musashi 1 Quote Link to comment Share on other sites More sharing options...
mos6507 Posted March 13, 2013 Share Posted March 13, 2013 I really don't think Ballblazer is the type of game that is best suited for a stock VCS, even a 32K superchip one. I know Tod Frye said he had a kernel going, and I think that is the origin of this idea, but just because he had a kernel demo doesn't mean he could have done the whole game back then. I think that is being proven in how this game has progressed. Tod was a better coder than he ever got credit for, but this game is pushing the envelope about as far as it goes. As far as extra hardware, remember that homebrew hardware had to actually be designed to assist the VCS. This required a lot of very tricky engineering, and an intimate knowledge of the VCS is at the center of it. So using Harmony/Melody is very in-keeping with the sprit of homebrewing. If these carts were really expensive, that's one thing, but they're not. These ARM chips that cost so little run faster than my Amiga editing system that I produced Stella at 20 on. DPC chips were only possible back in the day because Activision could actually afford to mass-produce a custom chip. It's a lot cheaper to use ARMs with firmware vs. FPGAs. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 21, 2013 Share Posted March 21, 2013 I really don't think Ballblazer is the type of game that is best suited for a stock VCS, even a 32K superchip one. I know Tod Frye said he had a kernel going, and I think that is the origin of this idea, but just because he had a kernel demo doesn't mean he could have done the whole game back then. I think that is being proven in how this game has progressed. Tod was a better coder than he ever got credit for, but this game is pushing the envelope about as far as it goes. As far as extra hardware, remember that homebrew hardware had to actually be designed to assist the VCS. This required a lot of very tricky engineering, and an intimate knowledge of the VCS is at the center of it. So using Harmony/Melody is very in-keeping with the sprit of homebrewing. If these carts were really expensive, that's one thing, but they're not. These ARM chips that cost so little run faster than my Amiga editing system that I produced Stella at 20 on. DPC chips were only possible back in the day because Activision could actually afford to mass-produce a custom chip. It's a lot cheaper to use ARMs with firmware vs. FPGAs. Sometimes it's not about practicality: it's about surpassing expectations. You already know that, though. http://www.atariage....50#entry2441539 Quote Link to comment Share on other sites More sharing options...
roland p Posted August 28, 2013 Share Posted August 28, 2013 (edited) Ok, I now have this crazy idea. Get rid of the extra rom and ram. With extra rom you're tempted to create extra code which isn't always good as it takes cycles to execute. For speed optimisations it's ok, but quickly you'll be adding features because you just have extra rom and you end up with bloated code. Extra ram is nice too, but filling that ram takes cycles too. A few days ago I decided to make the ballblazer kernel as light as possible and I ended up with a kernel of 2K. It has some black bars left and right but it looks really nice. It has the following improvements: - tile setup code has been interleaved with the checkerboard lines. The blank lines is where the decision is made which tiles to display. So it doesn't take extra ram since it only fills the X register which is used the next line. (see debugger in stella) - no extra ram needed for the sprites, only 2byte pointers. - since the tilesetup code is not in the sky-part anymore, but in the checkerboard kernel, the sky kernel is a big void of unused cycles . I have the idea to put some of the pseudo 3d>2d calculations here. - ROM is 4K again. I'm going to increase this only when it is realy needed. (Ofcourse it would be really cool if the game would fit in 4K...) - Extra black bars left/right makes sprite masking easy. (it's a feature! ) A demo is attached for those interested. Sprites will be the next thing I'll make. When all view stuff is done I'll bother with the gameplay code. rom.bin Edited August 28, 2013 by roland p 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 28, 2013 Share Posted August 28, 2013 The smell of a burnout... Quote Link to comment Share on other sites More sharing options...
roland p Posted August 28, 2013 Share Posted August 28, 2013 (edited) The smell of a burnout... My car has traction control On a serious note, maybe I am a bit burned out on ballblazer, but I like fiddle around, so as long as it makes me happy I'll fiddle around. Edited August 28, 2013 by roland p 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 28, 2013 Share Posted August 28, 2013 Seems to be very slow compared to what came before. Have you tried using DPC+? I think that's supposed to help do certain things faster without eating up cycles. Quote Link to comment Share on other sites More sharing options...
djmips Posted August 28, 2013 Share Posted August 28, 2013 I like the simple version. Is there source for this one? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 28, 2013 Share Posted August 28, 2013 Seems to be very slow compared to what came before. Have you tried using DPC+? I think that's supposed to help do certain things faster without eating up cycles. IMO using DPC+ makes little sense if you want to stay within the original limits. 1 Quote Link to comment Share on other sites More sharing options...
roland p Posted August 28, 2013 Share Posted August 28, 2013 (edited) Seems to be very slow compared to what came before. Have you tried using DPC+? I think that's supposed to help do certain things faster without eating up cycles.Its slow because I left out the gamelogic. Maybe the DPC+ helps with displaying more/better sprites. But only if the code has enough cycles to calculate them... But I like to keep it simple. Edited August 28, 2013 by roland p Quote Link to comment Share on other sites More sharing options...
roland p Posted August 28, 2013 Share Posted August 28, 2013 I like the simple version. Is there source for this one? I'll post both versions when I'm near my pc. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 28, 2013 Share Posted August 28, 2013 IMO using DPC+ makes little sense if you want to stay within the original limits. If you want to stick to the original limits, you can't go above 2k. 1 Quote Link to comment Share on other sites More sharing options...
roland p Posted August 28, 2013 Share Posted August 28, 2013 Here is the complex ballblazer and the simple ballblazer source code. ballblazer lite.zip ballblazer complex.zip Quote Link to comment Share on other sites More sharing options...
Keatah Posted August 28, 2013 Share Posted August 28, 2013 (edited) An awesome project to be sure, but to be straight and to the point - I like some of the older playfields better. They had a nicer feel to them. I'm personally not too concerned with staying "authentic" and period-memory-size-correct and all that. As a gamer and non-technical layperson all this coding stuff is way way beyond me, I play the game to enjoy the aura and graphics and all that 1970's stuff. To me, if it fits in the hole it's going in! (cartridge in da'slot) Edited August 28, 2013 by Keatah 1 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.