| Posted By
Sirhadisen
on 2023-07-07
08:41:00
|  Flickering PETSCII software sprites
Hello folks,
I am working on a new project: I want to have steerable b/w "PETSCII gifs" of the dimensions 12 by 20 characters that are created by a drawing routine that is integrated into a switchable IRQ-extension that leaves the BASIC interpreter intact.
I create the frame sequences as png files in Pixelorama, convert to human-readable ppm files with Irfanview, and use a Python script that creates tables with the hex codes of the PETSCII symbols that represent the images.
Unfortunately, too much time seems to pass between the restoration of the background in one loop and drawing the next frame in subsequent loop, so that the upper part of the frames flickers. I played with synchronization based on $FF1D, but that only reduced the flickering partially.
Another radical idea would be not to write into the video matrix directly, but into a 1K buffer from where the final result of (background restoration & next frame drawing) is copied into the video matrix in a single loop. However, sacrificing 1K for this task seems to be sub-optimal.
Any ideas? I would be glad to share the code I have so far.
|
|
Posted By
Csabo
on 2023-07-07
08:55:31
| Re: Flickering PETSCII software sprites
You're on the right track, and the two methods you described are the major approaches.
If you only use "one screen", you should always draw the areas that are not being displayed to avoid flicker. This is done with FF1D or raster interrupts. This will give you "full frame-rate", 50 FPS on PAL (and I'll just mention that in our demoscene, this is sometimes referred to as "realtime", even though that's a misnomer).
Otherwise you can use double-buffering. The idea is still the same - you draw to a place that's not being displayed. Since it's super easy to switch the location of the video ram with $FF14, this is easy to implement. No matter how many frames it will take for you to draw a full screen, you can just switch to it when you're done, then start drawing to the other one. It's not full frame-rate, but absolutely flicker-free (and it costs more memory).
Hope this helps 
|
|
Posted By
Sirhadisen
on 2023-07-07
09:16:18
| Re: Flickering PETSCII software sprites
Thank you Csabo, modifying the $FF14 was a great hint! I will try that next.
Just in case anyone else wants to contribute their ideas, here is the structure of my code, explicitly including the skipping counters and synchronization loops I used. The cause of the flickering is located in the 4 subroutines called at $A563:
--- $0357-$038B Universal RAM-access stub
-- skip IRQ-extension unless skipping counter has reached 0, in which case it is reset to #$04
.0357 dec $d3
.0359 bne $
.035b lda #$04
.035d sta $d3
-- detect key strokes with SCNKEY GETIN and cache in $E5
-- raster line synchronization for music (line #$10 seemed to be a good balance)
.036d lda #$10
.036f cmp $ff1d
!.0372 bne $036f
.0374 - .037a nop
-- bank-Switching ROM->RAM
.037a sta $ff3f
.037e jsr $A500
-- bank-Switching RAM->ROM
.0381 sta $ff3e
.0384 jmp $ce0e
--- $A500-$A57D Usagi moves: IRQ animation player main
[do a lot of stuff ...]
-- apply additional skipping counter for the animation routines
-- Note: Should be adjusted with the others to keep a regular reoccurrence of keyboard scans that supports a fluent animation
.a54a dec $e1
.a54c bne $a585
.a54e lda #$03
.a550 sta $e1
.a552 - .a562 nop
-- call background restoring routine, call update next frame metadata, call move column offset routine, call drawing routine
.a563 jsr $a660
.a566 jsr $a880
.a569 jsr $a8a0
.a56c jsr $a590
.a56f - .a577 nop
-- promote pointer1 to next frame
-- if width of next frame is 0 (= after finishing an animation), set idle flag to enable keyboard scanning at the beginning of the next step
.a58f rts
--- $A590-$A61C Drawing routine (can only handle rectangular frames with an even number of up to 254 cells!)
--- $A630-$A64B Copy TED base address to other STA and LDA statements (self-modifying code)
--- $A660-$A671 Background restoring routine
-- set pointer2 to starting address of memorized background behind current frame
-- call drawing routine with process flag set to restore background without memorizing current frame and without skipping transparent cells
--- $A680-$A77F region for memorizing the background character bytes
--- $A780-$A87F region for memorizing the background attribute bytes
--- $A880-$A89F Update next frame info
--- $A8A0-$A8C8 Move column offset for left/right moves
|
|
Posted By
MMS
on 2023-07-12
17:46:40
 | Re: Flickering PETSCII software sprites
Some time ago I though about the animation possibilities on the Plus/4.
I wanted to make a rotating car from Need For Speed III.
The idea is to use the full charset in multicolor mode, and the chars more or less simulating the multicolor mode, with 2 fixed colors and one free color per attribute. The size could be 20x12 or 12x20 to fit into the 256 characters. the color memory map takes only 480 bytes.
One frame of the animation is one charset. You load the charsets and the color maps of the frames into the memory, at every 2000bytes. Changing the picture is simply to change the charset address and copy the color map (or even better: just change it's address too), writing few bytes into registers. When it happens at the border, you may have flicker free smooth animation, as the change of few bytes takes no time.
(maybe it does not work at all, but I think I saw some 2-3 colored 3D animations/quickly morphing object in demos supposely using the same method)
|
|
Posted By
Sirhadisen
on 2023-07-19
19:42:48
| Re: Flickering PETSCII software sprites
Hi MMS,
Thanks for your input! Sounds like the next level FF14 switching. I already spent outrageous 24 blocks on my bare frames and still seek a "surrounding" game as a use case  1k per buffer might not be too bad. I still have to learn how to time music, drawing routines and (possibly) BASIC interpreter in direct mode simultaneously.
I just love the idea of being able to interrupt games and look under the hood! It's a thing I've never been granted in the old days...
Oh, and for now I'll stick to newbie b/w animation and coloured static background
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
