| |
Xenox
Registered: Jun 2003
Posts: 87 |
Datastorm Demo effects - awesome!
I'm really shocked about the very good quality of the demos released at the Datastorm2014, really, really great stuff, the gfx are amazing with very good code and music...!
I really, really, like the bg Datastorm bitmap picture in "We are all connected" at the beginning...
My question is, how do they do that moving the bitmaps... i'm really impressed...!
We Are All Connected
Frank |
|
... 27 posts hidden. Click here to view all posts....
|
| |
Killsquad
Account closed
Registered: Jun 2005
Posts: 17 |
Quote: No, square 1 was:
"My question is, how do they do that moving the bitmaps... i'm really impressed...!"
No magic, just 25 fps and lda+sta which gives plenty of time for load and decrunch.
BUT, if you want 50fps you need something else, but that's not square 1. ;)
My bad then, I thought your reply was directed to another post :) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
I don't see any problems in scrolling this by copying. Just do it the same style as with a doublescreen picture + add a ringbuffer from where you copy the new slices needed. The ring buffer will be filled by a loader+decruncher. So not much memory managment necessary. Doynax even brings along all things that is required to easily operate such a ringbuffer.
http://www.codebase64.org/doku.php?id=base:double_screen_vertic..
And to launch the long copy job from an irq (so that loader and depacker can still run in the mainloop) you might do the following:
http://www.codebase64.org/doku.php?id=base:launching_long_tasks..
Basically similar stuff as being used in the greetingspart of coma light 13, just that 3 frames where calculated in advance in a triple buffer to get over some cases that use too much cpu. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
just be careful with starving the loader for CPU. Krill's loader has a timeout, and it will reset the drive after a few frames of no response from the c64 :) Couldnt solve this problem in 'Still Ready' so had to postpone the loading to after the effect :( |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
have a quick look into the config.inc and you'll find:
!set DISABLE_WATCHDOG =1
Easy like that :-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
yeah, krill told us about the watchdog, we tried take it out, but didnt work. Time pressure was too big to track it down. Probably something got mixed up and the watchdog was still in there. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Solution: Never use someone elses (drive-)code. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Solution: Don't do demos anymore :-P |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting BitbreakerSolution: Don't do demos anymore :-P
Nah, following up on HCL's idea, the next logical step is of course to build your own computer and only make demos for that. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Solution: Never use someone elses (drive-)code.
also write your own assembler, while you're at it. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
For the moving bitmaps in We Are All Connected, I divide the images into 96 pixels wide segments, and load data into two alternate buffers, each 4096 bytes long (2400 bytes for the bitmap data, 300 bytes for the screen data, and the rest available for sprite data, tables, code or whatever.) Some of the segments are crunched to almost nothing, so they will finish loading and decrunching very soon after I start copying data from the previous buffer onto the screen, that's why I didn't bother coding a ring buffer. Also, I am lazy. |
| Previous - 1 | 2 | 3 | 4 - Next |
