Hi guys!
For all Amstrad CPC models, all CRTCs, it features:
* a 3D starfield, nearly 100 stars
* in overscan (384x256 instead of the normal 320x200)
* plus a scrolltext
*
all animated at solid 50Hz* with music by The Other Days
Yes, you read that well: an overscan true 3D starfield on the CPC!
Feel free to visit 2021 a CPC Odyssey by cpcitor + The Other Days :: pouët.net (https://www.pouet.net/prod.php?which=89060) and vote your opinion there.
You'll find:
- disk image to run in your favorite emulator,
- and also videos, one specially adjusted for 60Hz screen (most screen nowadays)
- and a video in genuine 50Hz if you can set your display to 50Hz or 100Hz.
I'm planning to release source code under an open source license (needs some cleanup for now). Feel free to ask for it.
Just watched the video (no CPCs here at work - shock, horror), really really nice and the scroller zips along very nicely :)
Very nice! Cool tune too.
However, sorry to say something that may sound negative, but contrary to what you said in the scroller, the starfield had already been done before... and in a better way (in my opinion). Did you check the RTS demo by Jack (https://www.cpc-power.com/index.php?page=detail&num=7406)?
Congrats anyway and looking forward to play your game as a stand-alone!
Thanks Targhan! I could not find a previous prod doing it, and this link is really relevant!
RTS demo is really nice indeed!
Ow, what is written in pouet.net is true: it crashes after a moment (maybe 10 minutes).
I will step through the code to understand how he did it.
Since the part do not last long, I'm suspecting there's some precalculation in the 10-20 seconds before.
"2021 a CPC Odyssey" actually computes the 3D in real time.
That's because of a difference in goal: intro and demo are byproducts for me, I'm aiming at a 3D fully immersive interactive game. So, 3D must be computed real time from player action.
Also, "2021 a CPC Odyssey" works even on a 464 with tape :-) although the future game will most certainly need a 6128.
Thanks again Targhan for the link, it's very interesting and relevant!
From what I recall by looking at the code, it is a simple projection using a 8-bit division, but I might be wrong. So, no precalculation from what I remember (contrary to Batman!).
Also, nice starfield by Face Hugger in the Mops megademo (https://www.cpc-power.com/index.php?page=detail&num=7546) (less accurate but translation in X/Y too).
Quote from: cpcitor on 12:39, 24 May 21
Since the part do not last long, I'm suspecting there's some precalculation in the 10-20 seconds before.
Hehe,. I guess the only reason it's short is because it tries to be a multipart. There is also 3d dots part later, with so few dots I am pretty guesing it's realtime.
Quote from: Targhan on 12:48, 24 May 21
Also, nice starfield by Face Hugger in the Mops megademo (https://www.cpc-power.com/index.php?page=detail&num=7546) (less accurate but translation in X/Y too).
Oh yeah, I remember that one.
Was there another better starfield with also translation on X/Y but in a secret part of a particular demo? I remember someone showing me at ReSeT, can't remember the demo, maybe an old 90s french demo, but I wondered hey that's cool, why hiding it in a secret part?
Nice!
How did you adjust to 60 hz? Did you just play the frames faster?
Quote from: mr_lou on 17:57, 24 May 21
Nice!
How did you adjust to 60 hz? Did you just play the frames faster?
Yes. A demo scrolltext must be smooth, or must not be. That is the question. ;)
After researching solutions, I combined the normal soundtrack with the same frames played at 60fps instead of 50fps, which makes a shorter video. That's why I put a text overlay to make clear this is adjusted.
This is an interesting topic.
The solution, I think is to write modern productions with 60Hz in mind, even 50Hz/60Hz compatibility. This is as easy as adjusting screen dimensions, easier than enabling overscan. Of course the prod should be ready to have 1/6 less time for the Z80, that is 16640 NOPs per frame instead of 19968 NOPs per frame.
Since the CPC supports 60Hz prod when hooked to a 60Hz capable screen, the only missing piece is emulators that support 60Hz prod.
To help this, I just posted this extremely long post full of details about how this could work https://www.cpcwiki.eu/forum/emulators/wish-60hz60fps-support-in-emulators-thought-on-emulating-a-crt/msg2023161/#msg202316
Quote from: cpcitor on 23:20, 24 May 21Yes. A demo scrolltext must be smooth, or must not be. That is the question. ;)
There is no question: It must be smooth!
But I know the majority sadly doesn't care at all. In fact, most people doesn't even seem to notice the jerky movement. We're outsiders.
Quote from: cpcitor on 23:20, 24 May 21After researching solutions, I combined the normal soundtrack with the same frames played at 60fps instead of 50fps, which makes a shorter video. That's why I put a text overlay to make clear this is adjusted.
I did something similar for 8-bit Memoirs. Since the CPC is 50.04 Hz, I turned it down to an even 50 hz, and stretched the audio to match. It's so little that no one can hear it, but the result is awesome. All videos are as smooth as a baby's butt, just the way God intended.
I would never have been satisfied with 8-bit Memoirs if it had been made as a web-project, and thus running on a 60 hz screen. By going with Blu-ray, all videos give a much more authentic impression of the CPC. (Except of course if playing the ISO on a PC with a media player - but any real blu-ray player makes sure the display switches to 50 hz, and to this day it still pleases me :) ).
Quote from: cpcitor on 23:20, 24 May 21The solution, I think is to write modern productions with 60Hz in mind, even 50Hz/60Hz compatibility. This is as easy as adjusting screen dimensions, easier than enabling overscan. Of course the prod should be ready to have 1/6 less time for the Z80, that is 16640 NOPs per frame instead of 19968 NOPs per frame.
Interesting concept. I can't imagine anyone will embrace though. Deviating from the standards of a plain CPC464 is often frowned upon, I've noticed. But of course, a higher framerate could sound interesting to some.
Quote from: Targhan on 12:48, 24 May 21So, no precalculation from what I remember.
Do you really think that the top 8-bit, 16-bit demos outside of the CPC scene aren't precalculated?
Smooth! I like the starfield. :)
Quote from: MaV on 10:52, 25 May 21
Do you really think that the top 8-bit, 16-bit demos outside of the CPC scene aren't precalculated?
Only when you're one of the Meteoriks' judges and you're looking for a plausible lie to give an award to your mates instead of the entry that actually deserves it... *cough*
Quote from: pelrun on 11:20, 25 May 21
Only when you're one of the Meteoriks' judges and you're looking for a plausible lie to give an award to your mates instead of the entry that actually deserves it... *cough*
:o
Quote from: pelrun on 11:20, 25 May 21Only when you're one of the Meteoriks' judges and you're looking for a plausible lie to give an award to your mates instead of the entry that actually deserves it... *cough*
:D I'm sensing a story here that I apparently missed out on.
@the 50/60Hz discussion: Doable on the CPC, but having 3328 NOPs less frame time hurts quite a bit.
Other platforms which only need minor modifications to switch to 60Hz also do not embrace it:
TiTAN - Overdrive 2 (RGB 50fps) - SEGA Mega Drive - Revision 2017 (1st Place) - YouTube (https://www.youtube.com/watch?v=gWVmPtr9O0g)
D-Zero by Desire (2021) | Nintendo SNES Demoscene - YouTube (https://www.youtube.com/watch?v=SC9hjhiJ1DI)
The SNES and Megadrive sold with 50 Hz enabled in PAL countries (and we suffered for it because games usually were programmed with 60Hz and the US and Japanese market in mind, and then simply slowed them down to 50Hz with black bars on top and bottom). Current demos on old platforms all use 50 Hz because it's largely (pre-dominantly) a European thing, even though modern hardware has switched to 60 Hz.
It would be better to beg emulator-devs to add a fullscreen mode that toggles screen refresh rate to 50 hz.
Quote from: MaV on 10:52, 25 May 21Do you really think that the top 8-bit, 16-bit demos outside of the CPC scene aren't precalculated?
Mmmh, no, and I never said that wasn't the case. I just said that I think the RTS is real-time, from what I remember.
https://youtu.be/npRnieCYkx8
Er...... why does the embedded version look less smooth / more blurry than if you watch the exact same video on YouTube?
Quote from: MaV on 10:52, 25 May 21
Do you really think that the top 8-bit, 16-bit demos outside of the CPC scene aren't precalculated?
you don't need to precompute until many many many more dots ;D
@cpcitor (https://www.cpcwiki.eu/forum/index.php?action=profile;u=531) you claims there is no cheat or trick but starfield is going the same way all the time, why? :P
Quote from: roudoudou on 17:28, 25 May 21
you don't need to precompute until many many many more dots ;D
@cpcitor (https://www.cpcwiki.eu/forum/index.php?action=profile;u=531) you claims there is no cheat or trick but starfield is going the same way all the time, why? :P
I don't understand your question. Can you be more precise about each element of your question?
Quote from: cpcitor on 18:24, 25 May 21
I don't understand your question. Can you be more precise about each element of your question?
A true 3D starfield must be free directionnal (also named freedir), not only from back to front
Quote from: roudoudou on 18:36, 25 May 21
A true 3D starfield must be free directionnal (also named freedir), not only from back to front
Never heard about such a rule. Anyway, this was submitted to Shadow Party, where rules say "non-interactive" and that allows all the optimization you want. Precalculation is totally okay in this spirit. So, trick not cheat.
In my case, since the 2D coordinates are calculated real time for each frame, I could have adapted this to other directions by adding an offset, at the cost of some cycles, I just didn't do it. Some demos like Phenomena demo do all directions and rotations and all, this is just an intro.
Not sure I get your point?
Quote from: roudoudou on 18:36, 25 May 21A true 3D starfield must be free directionnal (also named freedir), not only from back to front
So now we are rules in demomaking? Things will get boring very soon :). Don't worry @cpcitor (https://www.cpcwiki.eu/forum/index.php?action=profile;u=531), you did a very fine starfield :).
Quote from: Targhan on 20:54, 25 May 21
So now we are rules in demomaking? Things will get boring very soon :) . Don't worry @cpcitor (https://www.cpcwiki.eu/forum/index.php?action=profile;u=531), you did a very fine starfield :) .
what rules are you talking about?
Quote from: cpcitor on 20:05, 25 May 21
Never heard about such a rule.
it's not a rule, you said
true 3D so coordinates must be
true 3D => (X/Y/Z) then stars can move any direction easily.
for example, my 3D starfield in
Asic intro 2 is not a
true 3D starfield because perspective is cheated by increments of increments. And that technic does not allow free direction of starfield
That's not a "rule", that's, heeeeee, vocabulary, in order to differentiate technics
https://www.cpc-power.com/index.php?page=detail&num=13079
Quote from: roudoudou on 21:08, 25 May 21
A true 3D starfield must be free directionnal (also named freedir), not only from back to front
it's not a rule,
That's not a "rule", that's, heeeeee, vocabulary, in order to differentiate technics
Your sentence used the verb "must", which means, well "must".
Anyway, let's move on.
Quote from: roudoudou on 21:08, 25 May 21
you said true 3D so coordinates must be true 3D => (X/Y/Z) then stars can move any direction easily.
for example, my 3D starfield in Asic intro 2 is not a true 3D starfield because perspective is cheated by increments of increments. And that technic does not allow free direction of starfield
https://www.cpc-power.com/index.php?page=detail&num=13079
I did not know your prod. Thanks for the link.
Thanks for explaining. I get your point now.
In my intro, the stars have definite positions in 3D and can be moved in other directions by changing X and Y. I just happened to change only Z. (By the way, between each frame I change the observer position actually, but mathematically it is the same.)
So, I think it qualifies as a true 3D starfield in your vocabulary, even if it doesn't show the other directions. Anyway, most cheats would defeat the sensation of depth.
During elaboration of the intro I considered changing the directions, for example based on the music, but I couldn't convince myself I found a way to make a motion that would be somehow "natural". I remembered nice intros I had seen on the Amiga just had forward motion, which maximizes the perception of depth, which seems to me a more important goal.
At first the intro was 32char wide. I considered having it overscan was the most important improvement, and it was difficult enough to get it while keeping very fast code. When I had overscan working it was time to send the final version anyway.
Even if I had more time, I would probably have let this way. The direction I'm aiming for the future at is an immersive first-person 3D game. The "true 3D" will be even more obvious by then.
Quote from: roudoudou on 17:28, 25 May 21you don't need to precompute until many many many more dots
That means that precalculation is not disregarded entirely. However, I do often get quite the opposite impression here in the forum.
Why do stars not go through the scrolling text (behind or over it)? Doing this, it would have been a true innovation.
Quote from: Bug Powell on 17:22, 09 June 21
Why do stars not go through the scrolling text (behind or over it)? Doing this, it would have been a true innovation.
Thank you Bug Powell for your comment.
As one can see, this demo has a Amiga tribute spirit all over.
What is implemented is like a "video overlay": the test overlays the stars in its rectangular area, letting the stars be seen through anywhere else.
Just ignoring a possible interference between stars and scroll would result in ugly streaks (like dead flies stuck on the letters and scrolling with them).
Extremely few CPC demos implement 3D stars that at least seem (and perhaps are) genuinely 3D (actually, I know only 2 other examples), and I know
none that implements stars + the traditional 2D scrolltext in the Amiga spirit.
Achieving this clean overlay with fast code is already... an achievement and probably a true innovation given the CPC constraints.
As an example, renowned CPC coder norecess recognizes this as a "nice touch" on https://www.pouet.net/prod.php?which=89060#c924190 .
So, I do think it's a true innovation in the CPC context and constraints.
"Criticism is easy, and art is difficult." Philippe Néricault Destouches (https://en.wikiquote.org/wiki/Philippe_N%C3%A9ricault_Destouches)
I don't see why stars displayed over the text scrolling would be a problem.
Also, why having done a text scrolling not with using cpc hardware tricks?
To be honest, you speak a lot for an average intro. You should watch latest cpc demos to see true innovation.
Quote from: Bug Powell on 20:08, 09 June 21
I don't see why stars displayed over the text scrolling would be a problem.
Also, why having done a text scrolling not with using cpc hardware tricks?
To be honest, you speak a lot for an average intro. You should watch latest cpc demos to see true innovation.
We are looking forward to your upcoming releases. ;-)
villain: because we must have released something to be allowed to give an opinion?
Quote from: Bug Powell on 20:08, 09 June 21
I don't see why stars displayed over the text scrolling would be a problem.
Because it looks ugly :P
Quote from: Bug Powell on 20:15, 09 June 21
villain: because we must have released something to be allowed to give an opinion?
Of course not. Aber der Ton macht die Musik, as you probably know...
Quote from: Bug Powell on 20:08, 09 June 21
I don't see why stars displayed over the text scrolling would be a problem.
"Stars over the text" does not fit the design I wanted. No need for another reason.
Feel free to make an experiment, e.g. with your favorite image editor.
Then share it so anyone can give their opinion whether it's better or not than the prod.
It's much easier than changing assembly code.
This is a genuine, open, no mockery, no irony or whatever, suggestion.
Quote from: Bug Powell on 20:08, 09 June 21
Also, why having done a text scrolling not with using cpc hardware tricks?
To be honest, you speak a lot for an average intro. You should watch latest cpc demos to see true innovation.
A hint about the reason questioned in your first line is in the text you mention on your second line.
Regarding "I speak a lot", I invested many days making and polishing this prod. You can read the text for the few minutes it takes of your time. The pouet.net page 2021 a CPC Odyssey by cpcitor + The Other Days :: pouët.net (https://www.pouet.net/prod.php?which=89060) has links to Youtube videos. Decent youtube clients (including youtube.com website) allow changing speed and skipping/seeking at will. But I guess I join your opinion and might speak less in future prods, perhaps because there will be no scrolltext anyway.
Regarding "true innovation", it is my opinion that CRTC-tricks based demos is an overcrowded area with little room for anything new and interesting. I'm not interested in making yet another "the moving things you see are useless but not exactly equal to all previous demos, so you don't know how I did it and therefore you must be in awe" production. I'm rather interested in true innovation. That said, I did see interesting demos showing interesting techniques. Still they are like a demonstration of (great) strength and lack some kind of "unity" or "purpose" or "consistency". Ah, I got it: some seem
only/mostly guided by CPC limitations. I'm longing for something that breaks free from that approach.
My CPC prods are stepping stones validating tools and practices, on a multi-year journey towards a pinnacle production in an area very different from all demos in the "overcrowded area". There are hints about what it will be near the end of the text.
Quote from: Bug Powell on 20:08, 09 June 21
I don't see why stars displayed over the text scrolling would be a problem.
I have no motivation nor time to try that. You seem to have motivation to defend this case.
If you do make a screenshot of the prod and add dots to simulate stars in front, please share.
Sincerely,
-- cpcitor
Nice job cpcitor. I like the fact the dots go around the scroll, sweet touch.
I also love your approach! Let's do new effects on CPC and break some records.
For the record, a nice starfield in 1991's https://www.cpcwiki.eu/index.php?title=5KB_Demo_3 (https://www.cpcwiki.eu/index.php?title=5KB_Demo_3)
(cheat part).
Not overscan, but pretty dense (342 stars).
No forward direction, but X/Y, so still great 3d impression.
Quote from: cpcitor on 21:29, 09 June 21
Regarding "true innovation", it is my opinion that CRTC-tricks based demos is an overcrowded area with little room for anything new and interesting. I'm not interested in making yet another "the moving things you see are useless but not exactly equal to all previous demos, so you don't know how I did it and therefore you must be in awe" production. I'm rather interested in true innovation. That said, I did see interesting demos showing interesting techniques. Still they are like a demonstration of (great) strength and lack some kind of "unity" or "purpose" or "consistency". Ah, I got it: some seem only/mostly guided by CPC limitations. I'm longing for something that breaks free from that approach.
To be honest, most CRTC-tricks based demos will look the same, but in reality they might also make those small incremental steps from the personal view of the coder. They might try different techniques but it's so subtle that when I watch things I think it's the same. Now, a 3d stars scroller is more rare on CPC (but done before), so people think it's the same thing, with small innovations like overscan or a scrolltext over (but I don't understand the pouet comment, it was said the stars are going under the scroller, which initially made me think they will be showing inside the gaps between the letters but this is not the case (and I know this is harder to program, to check if a dot is in the scrolltext area and do a mask there or something)). So, I don't think there are any big innovations (like an entirely new effect or a novel way to do things) compared to other CRTC based demos which, yes, I will see one and be like "oh they same thing, I am bored" but incremental innovations are there, they are subtle in the same way as yours. And I like your demo, I prefer to see some software rendering 2d or 3d than another CRTC screen, but both of these kinds of demos do have their subtle small innovations from the coder's view. It's only when big demos like Batman Forever or the recent CRTC by benediction for example, have several new effects you haven't seen before counted, along with a trackmo design, that you are like, wow this is something the coders can brag about for sure, there are a lot of new things in one demo here.
Quote from: m_dr_m on 05:59, 10 June 21For the record, a nice starfield in 1991's https://www.cpcwiki.eu/index.php?title=5KB_Demo_3
(cheat part).
https://youtu.be/9M0OeadEQdE?t=665
Seems to me that's a totally different approach and cannot be compared. They are all moving into the same direction, just at different speed, giving a pseudo-3d-effect. At least that's my impression...
Quote from: m_dr_m on 05:59, 10 June 21
Nice job cpcitor. I like the fact the dots go around the scroll, sweet touch.
I also love your approach! Let's do new effects on CPC and break some records.
For the record, a nice starfield in 1991's https://www.cpcwiki.eu/index.php?title=5KB_Demo_3 (https://www.cpcwiki.eu/index.php?title=5KB_Demo_3)
(cheat part).
Not overscan, but pretty dense (342 stars).
No forward direction, but X/Y, so still great 3d impression.
Thanks m_dr_m! On some copies of the demo one finds on the Internet, call 0 after the reset does not trigger the hidden part.
Quote from: eto on 13:25, 16 June 215KB
Thanks eto, too, for the video!
Finally found a version where the "call 0" works.
Analysis of "5kb demo" assembly code and explanation about how it works.It looks like it's actually 3D.
But if you read to the end the 3D in 5kb demo is not totally right.
Let me see that code, thanks to the nice integrated disassembler in CPCEC-Plus (by Norecess, based on CNGSoft's CPCEC).
Overall memory structureCRTC view
0x4000-0x7FFF : image buffer 1
0xC000-0xFFFF : image buffer 2
CPU view
0x0000-0x3FFF : code
0x4000-0x7FFF : current image buffer
0x8000-0xBFFF : variable data
0xC000-0xFFFF : 3D table
Overall code structure* Looks like main loop starts at 0x192.
* Calls 0x189 which waits for Vsync.
* Double buffering between screens at 0x4000 and 0xC000 (CRTC view of memory), both mapped to 0x4000-0x7FFF (CPU view).
* RAM bank switching to allow reuse same tables for two buffers.
* From 0x33E, erasing the stars is done with an unrolled loop: "POP HL ; LD (HL), A" repeated 344 times from 0x34D to 0x5FD.
* Address of previous star positions stored from 0x8000 to 0x82B0 or 0x9000 to 0x92B0, depending on which of the two screen buffer.
* From 0x613 to just before 0x3C1D, an unrolled loop that does the actual coordinate update.
* From 0x266, keyboard handler.
The secret sauce of 5kb demoOkay, I got how this works. Impressive speed because the author(s) dared use a "complete" 3D table: given Z then X and Y it provides you directly with address and mask to plot. Now that's fast!
RAM between 0xC000 and 0xFFFF is structured as a 3-entry table:
64 entries of 256 bytes, one per Z value.
In each Z-indexed block of 256 bytes:
* lower 128 bytes contain 64 entries indexed by star's Y, 2 bytes each: MSB of target line, LSB of target line
* higher 128 bytes contain 64 entries indexed by star's X, 2 bytes each: bitmask that will target pixel, offset in bytes from start of line
So, there is indeed a 3D (in the sense of 3-entries) table of 3D-position-to-2D-pixel-as-address-and-mask (in the sense that all the 3D computation is done beforehand) that allows only by lookup to figure out address and mask. Well done!
Analysis of the central code "inner (unrolled) loop": it's actually table lookups plus some additions, (which is a very nice design).Here's a commented disassembly I just figured out, of the coordinate update + plot routine:
First, read, update and write new 3D coordinates.
#06A3 LD HL, #DF16 ; ZY coordinates, new value is stored by writing at 0x6A4
#06A6 LD A, H ; take Z coordinate (always between 0xC0 and 0xFF)
#06A7 ADD XH ; add Z speed
#06A9 OR #C0 ; keep in bounds
#06AB LD H, A ; store new Z
#06AC LD A, L ; take Y coordinate (always between 0x00 and 0x7F)
#06AD ADD XL ; add Y speed
#06AF AND #7E ; keep in bounds
#06B1 LD L, A ; store new Y
#06B2 LD (#06A4), HL ; store new ZY coordinates
#06B5 LD A, #A2 ; take star's X coordinate (always between 0x80 and 0xFF), new value is stored by writing at 0x6B6
#06B7 ADD B ; add X speed (to the left)
#06B8 OR #80 ; keep inside bounds
#06BA LD (#06B6), A ; store new star XThen, from those 3D coordinates, find out which byte and mask to plot to.
The value H determines which of the 64 Z-indexed entries we'll read. That does the actual 3D part. The rest is merely reading tables and doing one addition.
Read from that Y table:
#06BD LD D, (HL) ; read MSB of target line (from lower, Y-indexed table at Y coordinate)
#06BE INC L ; lower table, move to second byte
#06BF LD E, (HL) ; read LSB of target line (from second byte in same table)Read from that X table:
#06C0 LD L, A ; switch to higher, X-indexed table at X coordinate
#06C1 LD C, (HL) ; from first byte of that higher table, read bitmask that will target pixel
#06C2 INC L ; higher table, move to second byte
#06C3 LD A, (HL) ; from second byte of higher table, read offset in bytes from start of linePut correct target address in HL:
#06C4 ADD E ; add LSB of target line
#06C5 LD L, A ; LSB of target screen address
#06C6 LD H, D ; MSB of target screen addressPerform pixel draw:
#06C7 LD A, (HL) ; read target screen adress
#06C8 OR C ; enable pixel with correct mask
#06C9 LD (HL), A ; write target screen address with pixel added
#06CA PUSH HLRelative strengths an weaknesses of "5kb demo" stars and "2021 a space odyssey" stars.Now this analysis allows to compare strengths and weaknesses.
In favor of "5Kb demo"* "5Kb demo" stars code is faster than "2021 a space odyssey" code. Without the scrolltext mine should be capable of around 115 stars, plus without the music. This code spits 344 stars!
* "5Kb demo" shows motion in all 3 directions, plus combinations, while "2021 a space odyssey" only shows one direction
In favor of "2021 a space odyssey"* "2021 a space odyssey" shows an initial "appear" effect, while "5Kb demo" only has steady state behavior.
* "2021 a space odyssey" gets viewer immersed in a "big" universe, while "5Kb demo" shows "stars in a cube".
* "2021 a space odyssey" code is more precise than "5Kb demo". "5Kb demo" can only handle stars within a 64x64x64 chunk of 3D space. "2021 a space odyssey" can handle stars within a 256x256x256 chunk of 3D space, although in practice if you have N stars their motion is in a 256x256xN chunk of 3D space. That's why "5kb demo" stars have something grainy in their motion, while "2021 a space odyssey" stars have an unbeatable smooth motion.
* "2021 a space odyssey" has a bigger screen 384x256 overscan, rather than the 256x256 of "5Kb demo"
* "2021 a space odyssey" shows different per-Z star colors, while "5Kb demo" only shows white dots.
* "2021 a space odyssey" has a very log period (65535 frames), while "5Kb demo" has a short 64-frame period
* "2021 a space odyssey" is more portable: "5Kb demo" needs a CPC6128, "2021 a space odyssey" works on all CPCs, even a 464!
* "2021 a space odyssey" has a consistent "artistic" feeling, while "5Kb demo" feels like a tech demonstrator.
* Now the spoiler: I thought both were showing genuine 3D. "5kb demo" can show forward motion and that's where the illusion falls off. "5kb demo" has something wrong in the Z dependency. Stars supposed to be far away move closer much too fast. This makes moving towards the stars feels like watching a fountain, and moving away from the stars feels like looking at a washbasin emptying itself with sand at the bottom being dragged to the center by water motion. Effect is even more pronounced when combining forward and down motion, it looks like watching fireworks. "2021 a space odyssey" has all 3D maths right, that's why it's so immersive. 8)
If you want to reproduce the effects in "5kb demo", here are keys to move in 3D, each line in order : move, stop, move in the other direction.
* left, f2, right : left-right axis
* up, f3, down : up-down axis
* f0, ., f1 : forward-backward axis
Of course, anyone is allowed to disagree with any parts of this analysis. :)
I'm still impressed by 5kb demo anyway. 344 stars, man! And the wrong table computation could in theory be fixed.
All in all, I prefer my own prod. After all, I did it how I like it. :-)
Thanks for reading so far! Please share your opinion.
Quote from: cpcitor on 23:03, 22 June 21
RAM between 0xC000 and 0xFFFF is structured as a 3-entry table:
64 entries of 256 bytes, one per Z value.
In each Z-indexed block of 256 bytes:
* lower 128 bytes contain 64 entries indexed by star's Y, 2 bytes each: MSB of target line, LSB of target line
* higher 128 bytes contain 64 entries indexed by star's X, 2 bytes each: bitmask that will target pixel, offset in bytes from start of line
In comparison, "2021 a space odyssey" uses these tables (yes that's C, tables are declared in a C source file, then used from ASM):
uint8_t __at( 0x8000 ) math_square_div4_table_512_or_1024_bytes[1024]; // a precomputed look-up table
uint8_t __at( 0x8400 ) star3d_coord[256]; // star coords, they are not in an unrolled code loop
uint8_t __at( 0x8500 ) div_table[256]; // a precomputed look-up table
uint8_t __at( 0x8600 ) star3d_old_address_low[256]; // adresses where to erase stars
uint8_t __at( 0x8700 ) star3d_old_address_high[256]; // adresses where to erase stars
uint8_t __at( 0x8800 ) star3d_ink_dither[256]; // per-Z ink masks to use
uint8_t __at( 0x8900 ) cdtc_scr_48x32_table[3 * 256]; // table to transform X,Y into adress,mask
Total 3072 bytes of tables in "2021 a space odyssey", compared to 16384 + 344 * 4 = 17760 bytes of tables in "5kb demo".
I am a bit uncomfortable when comparing a prod of the nineties with one of today ;)
Current prods are done by guys that have collected 30 additional years of knowledge (or at least their knowledge rely on 30 additional years of knowledge in general computer programming).That makes any previous work of the nineties far more impressive than any modern work.
Also I guess that 5kb3 has not been done using crossdev that makes the result even more enjoyable (especially, by looking at your comments, knowing they use unconventionnal memory mapping that were probably breaking their coding environment).
Nombrilistic conclusion : So am I the only one to have released a starfield (not at all in real time) over several hardware scrollers ? https://www.youtube.com/watch?v=zhh1xZ6OXp8&t=1820s
Quote from: krusty on 15:42, 23 June 21
I am a bit uncomfortable when comparing a prod of the nineties with one of today ;)
Current prods are done by guys that have collected 30 additional years of knowledge (or at least their knowledge rely on 30 additional years of knowledge in general computer programming).That makes any previous work of the nineties far more impressive than any modern work.
Also I guess that 5kb3 has not been done using crossdev that makes the result even more enjoyable (especially, by looking at your comments, knowing they use unconventionnal memory mapping that were probably breaking their coding environment).
Thanks krusty for mentioning this. I thought about this then forgot due to the already too long message. Totally agree with you. There are
huge bonus points deserved by very old prods, and 5kb is an example.
Yes, though much of the knowledge about Z80 was "known" at the time, it was not readily available.
Plus the CPC was in most case the only machine. People coded directly on it.
I knew that era, I coded at the time, though I was a little too young and undocumented to do heavy ASM code on the CPC (I did BASIC and some ASM attempts including a simple little intro).
You know Shadow of Sergoth? It did not exist in the 90s but "Dungeon Master" on Amiga, Atari ST existed. So I coded, mostly in 1996 and 1997 DM48 http://amphi-gouri.org/hp48/dm48/#presentation all on the HP48! A handheld machine with 32 to 128k RAM, storage included (no disk drive, you crash the machine you lose your storage, but you can backup to an external machine through a 2400bps IR link or 9600bps serial link, in practice 100 bytes per second), and a 96x64 pixels screen.
(http://amphi-gouri.org/hp48/dm48/dmanimated.gif) (http://amphi-gouri.org/hp48/dm48/dmpreview.gif)
Quote from: krusty on 15:42, 23 June 21
Nombrilistic conclusion : So am I the only one to have released a starfield (not at all in real time) over several hardware scrollers ? https://www.youtube.com/watch?v=zhh1xZ6OXp8&t=1820s
What do you mean "not at all in realtime". Seems real time to me?
The link shows a starfield
under many scrolling text parts.
Yes I think it's a unique prod. How do you do it? The colored text moving around does not look like hardware scrolling.
QuoteWhat do you mean "not at all in realtime". Seems real time to me?
I mean the dots relative location to the monitor are dumbly read from a precomputed table. There is no multiplication/division there
QuoteHow do you do it?
I do not remember exactly, but I think that most code is in the bank as almost all main memory is taken by the text and the logo.Each text line is handled similarly to a byte-precision hardware left/right and right/left scroller by the CRTC (the difference is that there is no new block drawn on the left and right).The real dot position depends of course of the state of the screen (i.e. position of each split screen) when they have to be displayed
There is probably line to line splitting somewhere to have a smooth vertical movement, as I have never played with R5 of CRTC.
Quote from: cpcitor on 12:39, 24 May 21although the future game will most certainly need a 6128
Nice demo, and I like the sound of a future game... :)