| |
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 |
|
| |
Conrad
Registered: Nov 2006
Posts: 849 |
Just a guess but... VSP? |
| |
CRT
Registered: Oct 2012
Posts: 87 |
With double buffering and slow scrolling it's possible without VSP. |
| |
Scarzix
Registered: Aug 2010
Posts: 143 |
There was no VSP in our demo. :-) Perplex made the scroller. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
xenon: the power of lda+sta will give you scrolling, or if you're Mahoney, 44.1kHz samples. ;) |
| |
algorithm
Registered: May 2002
Posts: 705 |
you should be able to soft-scroll the whole screen in around 4 cycles with lda/sta which would be the equivalant of around 2 pixels hardware scroll per frame. If you need more cpu time for other things, then 1 pixel scroll per frame should be much more than sufficient. |
| |
algorithm
Registered: May 2002
Posts: 705 |
4 cycles?? Hahaah I wish... Meant 4 frames! |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Yeah, bitmap scrolling is definitely a new and revolutionary thing invented in 2014. :P |
| |
Xenox
Registered: Jun 2003
Posts: 87 |
Aeh, really? lda, sta? Hm, well, i remember that i used a fucking reat 4x4 charset from Compyx/Focus in a Intro years ago (Intro #19) using lda, sta to move the bitmap, but the routine eats the rastertime, so i'm not sure if this is working on a whole screen...! Doublescreen is a good idea...!
Frank |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting algorithmIf you need more cpu time for other things, then 1 pixel scroll per frame should be much more than sufficient.
Unless you want to do loading, decrunching and perhaps some other stuff at the same time, of course. |
| |
cg
Registered: Mar 2013
Posts: 2 |
Quote: xenon: the power of lda+sta will give you scrolling, or if you're Mahoney, 44.1kHz samples. ;)
lda+sta is the most versatile thing ever invented - any category ;) |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quoting PerplexQuoting algorithmIf you need more cpu time for other things, then 1 pixel scroll per frame should be much more than sufficient.
Unless you want to do loading, decrunching and perhaps some other stuff at the same time, of course.
Why would that be an issue? :-) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Guys... come on.
A hires bitmap is 9000 bytes colors included. If you move in 25fps like in the demo you will have 16 frames to render a new offscreen page scrolled one char. In total you'll need to perform 9000 lda+sta = 9000*8 = 72000 cycles. Divided on 16 frames => 4500 cycles per frame. I.e. about 20%-25% of available CPU-time. I.e. LOTs of time left for anything else, loading included. |
| |
TPM
Registered: Jan 2004
Posts: 110 |
Quote: Quoting algorithmIf you need more cpu time for other things, then 1 pixel scroll per frame should be much more than sufficient.
Unless you want to do loading, decrunching and perhaps some other stuff at the same time, of course.
i know the feeling ;) did lda/sta, 2 frames in http://csdb.dk/release/?id=105226, takes almost half the screen .. but like We Are Connected it's not thát hard.. memory management is harder, i think. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting TPMmemory management is harder, i think.
Indeed. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting JackAsserIn total you'll need to perform 9000 lda+sta = 9000*8 = 72000 cycles. Divided on 16 frames => 4500 cycles per frame. I.e. about 20%-25% of available CPU-time. I.e. LOTs of time left for anything else, loading included.
Yup, plenty of time, I have not claimed otherwise.
Double the scrolling speed though, and not only do you have to spend twice as many cycles on moving bitmap and screen data, you also have to load and decrunch new data twice as fast to keep up with the scrolling, and with much less free cpu time in which to do it. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quoting JackAsserIn total you'll need to perform 9000 lda+sta = 9000*8 = 72000 cycles. Divided on 16 frames => 4500 cycles per frame. I.e. about 20%-25% of available CPU-time. I.e. LOTs of time left for anything else, loading included.
Yup, plenty of time, I have not claimed otherwise.
Double the scrolling speed though, and not only do you have to spend twice as many cycles on moving bitmap and screen data, you also have to load and decrunch new data twice as fast to keep up with the scrolling, and with much less free cpu time in which to do it.
Well... that's why you don't normally scroll in 50fps for a bitmap scroller unless you resort to VSP. |
| |
Killsquad
Account closed
Registered: Jun 2005
Posts: 17 |
Quoting JackAsserWell... that's why you don't normally scroll in 50fps for a bitmap scroller unless you resort to VSP.
Which takes us back to square one (or post 10) ;-)
Quoting PerplexQuoting algorithmIf you need more cpu time for other things, then 1 pixel scroll per frame should be much more than sufficient.
Unless you want to do loading, decrunching and perhaps some other stuff at the same time, of course. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quoting JackAsserWell... that's why you don't normally scroll in 50fps for a bitmap scroller unless you resort to VSP.
Which takes us back to square one (or post 10) ;-)
Quoting PerplexQuoting algorithmIf you need more cpu time for other things, then 1 pixel scroll per frame should be much more than sufficient.
Unless you want to do loading, decrunching and perhaps some other stuff at the same time, of course.
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. ;) |
| |
enthusi
Registered: May 2004
Posts: 677 |
Hehe, I did bitmap scroll in 2014 too!
The Forest Deep |
| |
algorithm
Registered: May 2002
Posts: 705 |
I used it in the intro of Sabrina - The Demo
Large multiple screen tall bitmap with inline decompression in Algotecher
and in mcol-ci interlaced mode in Demolicious (Which needs to process twice the amount of pixels) |
| |
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. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: 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.
And following on that, Build the tools that are required to make the computer and also ensure that you build what is required to make the tools.. and also ensure... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:also write your own assembler, while you're at it.
didnt every coder write at least one of them? :) |
| |
soci
Registered: Sep 2003
Posts: 480 |
Quoting GroepazQuote:also write your own assembler, while you're at it.
didnt every coder write at least one of them? :)
I don't know what you're talking about ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
subliminal message ... we need a proper open source rewrite of "pack64" and "cruel" as well, if only for historic reasons ...
|
| |
soci
Registered: Sep 2003
Posts: 480 |
I've heard that there's some old source which would need pack64. I'm on the same opinion that it's better to replace it with a modern packer. Those two tools would need a rewrite from scratch otherwise. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Or if you're Chuck Moore, you then go on to build your own CPUs by laying out gates by hand using software you wrote in the language you wrote then ported to the previous generation of hardware you designed.. |
| |
Tao
Registered: Aug 2002
Posts: |
Quote: I've heard that there's some old source which would need pack64. I'm on the same opinion that it's better to replace it with a modern packer. Those two tools would need a rewrite from scratch otherwise.
An open source (binary compatible) cross-platform implementation of Blitz! would be awesome too, preferably in C :) (yeeees, it "might" have something to do with easing my C*Base workflow). |
