Secrets of Speed

[flashjazzcat]

Code in zp never lit my fire, I must admit.

[MaPa]

IMHO code in ZP runs at the same speed as elsewhere. It's about addresses of operands of the instructions.

[Rybags]

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.

[Heaven/TQA]

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...

[Heaven/TQA]

fex. Glenches by Probe has a simple edge filler put into ZP.

 

http://sources.pigwa.net/?page=1

[dmsc]

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

[+Stephen]

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.

[bugbiter]

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

[dmsc]

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

[bugbiter]

Thanks! Now I have to find out how to use CA65 and how the whole project structure is working.. :-)

[sack-c0s]

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

[Heaven/TQA]

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.

[+Philsan]

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!

[bugbiter]

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 2022.atr

[Harry Potter]

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!

[rensoup]

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 !