flashjazzcat Posted November 7, 2014 Share Posted November 7, 2014 Code in zp never lit my fire, I must admit. Quote Link to comment Share on other sites More sharing options...
MaPa Posted November 7, 2014 Share Posted November 7, 2014 IMHO code in ZP runs at the same speed as elsewhere. It's about addresses of operands of the instructions. Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 7, 2014 Share Posted November 7, 2014 Yep, really it needs to use self-modifying code and be called often enough to justify the use. Common cases there being DLIs (savings can be had by simply storing registers straight to load immediate instructions rather than normal stack handling) and sound playback by Timer IRQ where every cycle saved becomes critical. A process like this might be candidate if the savings can be had - but developing stuff as self-modifying code from the onset can be a pain. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 7, 2014 Share Posted November 7, 2014 vector filling routine could benefit... my latest ZP experiences are using them as linebuffer and or ZP as pointers to texture lines... as updating ZP for lookups is faster... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 7, 2014 Share Posted November 7, 2014 fex. Glenches by Probe has a simple edge filler put into ZP. http://sources.pigwa.net/?page=1 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted November 10, 2014 Share Posted November 10, 2014 Hi again! I updated my code to use text data in the scroll, attached is the resulting .xex and the source code in ca65 format. It probably can be optimized further, and using DLI the colors could be changed to attenuate the top parts. scroll.zip scroll-source.zip 2 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted November 10, 2014 Share Posted November 10, 2014 Hi again! I updated my code to use text data in the scroll, attached is the resulting .xex and the source code in ca65 format. It probably can be optimized further, and using DLI the colors could be changed to attenuate the top parts. Wow - that's really nice. Thanks for the source. Quote Link to comment Share on other sites More sharing options...
bugbiter Posted November 10, 2014 Author Share Posted November 10, 2014 (edited) Hi again! I updated my code to use text data in the scroll, attached is the resulting .xex and the source code in ca65 format. It probably can be optimized further, and using DLI the colors could be changed to attenuate the top parts. I'm speechless! unfortunately I don't use CA65, can I port the source to ATASM or some other assembler? Also, the xex wont run on a real atari, DOS2.5 gives me an error 136.. Edited November 10, 2014 by bugbiter Quote Link to comment Share on other sites More sharing options...
dmsc Posted November 10, 2014 Share Posted November 10, 2014 Hi, I'm speechless! unfortunately I don't use CA65, can I port the source to ATASM or some other assembler? Also, the xex wont run on a real atari, DOS2.5 gives me an error 136.. Thanks, and yes, you can do anything with the code, just respect that I originally write it. I prefer CA65 as it is possible to write relocatable code, so multiple routines can allocate ZP and RAM any way. Also, you are right, it wont run on DOS2.5 but runs in MyDOS :-( This is the fixed source and XEX. scroll.zip scroll-source.zip 1 Quote Link to comment Share on other sites More sharing options...
bugbiter Posted November 10, 2014 Author Share Posted November 10, 2014 Thanks! Now I have to find out how to use CA65 and how the whole project structure is working.. :-) Quote Link to comment Share on other sites More sharing options...
sack-c0s Posted November 22, 2014 Share Posted November 22, 2014 (edited) Good old misdirection also works, although not technically optimisation you can just draw attention away from the real framerate. For example, Imagine a spinning cube bouncing around the screen. You have translation (the movement around the screen) and rotation (the actual spinning). If you were to do the movement by moving the screen scrolling or the sprites that the cube is rendered to in the vsync interrupt then that happens at 50/60fps. The main loop will just be redrawing the spinning as fast as it can, which may be every 2-3 frames, but the eye will be tricked by the smooth movement and it'll appear faster than it actually is. Framerate isn't as important as consistency - people are far more adept at noticing a changing framerate. if you keep bouncing around between 40-50fps just lock it at 30 and it'll seem far smoother and buy you some more time. Edited November 22, 2014 by sack-c0s 2 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 22, 2014 Share Posted November 22, 2014 Sack... that's exactly what I am doing right now in my latest production.... and while study Lucasfilm games... look esp. RoF how they "distract" peoples attention to hide their short cuts... (by sound and visuals). the game engine itself runs at 50/60 fps... (joystick, movement, game world updates) while gfx engine not. 3 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted May 4, 2018 Share Posted May 4, 2018 Hi, Thanks, and yes, you can do anything with the code, just respect that I originally write it. I prefer CA65 as it is possible to write relocatable code, so multiple routines can allocate ZP and RAM any way. Also, you are right, it wont run on DOS2.5 but runs in MyDOS :-( This is the fixed source and XEX. FastBasic version please! Quote Link to comment Share on other sites More sharing options...
bugbiter Posted November 11, 2022 Author Share Posted November 11, 2022 After eight years I started to meddle with my Star Wars crawl a bit and I made some alterations. It now uses wide screen mode and the source graphics is now a 256 pixel wide bitmap which allows more detailed text so I made an almost screen accurate lettering with a font similar to the movie. And I finally got rid of the ugly jagged graphics- for 30 years now (I started that thing around 1990) I thought it was lack of precision of the scanning routine, but I just missed to align each line correctly with the right scan width.. vertical lines are now smooth as they should be. No changes on the speed here - the framerate is as slow as it always was - but in Altirra with warp speed mode on it looks quite nice 🙂 crawl.mp4 CRAWL 2022.atr 7 Quote Link to comment Share on other sites More sharing options...
Harry Potter Posted November 17, 2022 Share Posted November 17, 2022 Hi! I have five lists of ten cc65 code optimizations each at c65 additions - Manage Files at SourceForge.net. They are meant for cc65 C code, but some of their optimizations can be done on other C compilers or other compilers. Try them out! Quote Link to comment Share on other sites More sharing options...
rensoup Posted November 17, 2022 Share Posted November 17, 2022 On 11/11/2022 at 3:35 PM, bugbiter said: After eight years I started to meddle with my Star Wars crawl a bit and I made some alterations. Just noticed this thread, a fun problem indeed! You mentioned doing the proper (aliased) zooming method. That is indeed the right way but for starwars type of scrollers you may be able to get away with an incremental one. The demo group Sanity on Amiga were amazing at this, they were the first to show off 4bitplane fullscreen real time zooms but it didn't look that great probably because it was using the incremental method ? However I'm guessing their Starwars scroller from the same demo also uses that method, yet looks better: Or you could do it the old atari ST way: ...Preshift all the font sizes ! 1 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.