True 3D starfield in overscan: "2021 a CPC odyssey" by cpcitor

[roudoudou]

So now we are rules in demomaking? Things will get boring very soon . Don't worry @cpcitor, you did a very fine starfield .

what rules are you talking about?

[roudoudou]

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

[cpcitor]

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.

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.

[MaV]

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

[Bug Powell]

Why do stars not go through the scrolling text (behind or over it)? Doing this, it would have been a true innovation.

[cpcitor]

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

[Bug Powell]

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.

[villain]

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

[Bug Powell]

villain: because we must have released something to be allowed to give an opinion?

[SkulleateR]

I don't see why stars displayed over the text scrolling would be a problem.

Because it looks ugly 

[villain]

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

[cpcitor]

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.

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

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

[m_dr_m]

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
(cheat part).
Not overscan, but pretty dense (342 stars).
No forward direction, but X/Y, so still great 3d impression.

[Optimus]

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.

[eto]

For the record, a nice starfield in 1991's https://www.cpcwiki.eu/index.php?title=5KB_Demo_3
(cheat part).

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

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

5KB

Thanks eto, too, for the video!


Finally found a version where the "call 0" works.

[cpcitor]

Analysis of "5kb demo" assembly code and explanation about how it works.

It looks like it's actually 3D.

Spoiler: ShowHide

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 structure

CRTC 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 demo

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

Code Select Expand

    #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 X

Then, 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:

Code Select Expand

    #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:

Code Select Expand

    #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 line

Put correct target address in HL:

Code Select Expand

    #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 address

Perform pixel draw:

Code Select Expand

    #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 HL

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

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.

[cpcitor]

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):

Code Select Expand

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

[krusty]

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 ?

[cpcitor]

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.

Nombrilistic conclusion : So am I the only one to have released a starfield (not at all in real time) over several hardware  scrollers ?

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.

[krusty]

What 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

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

[ralferoo]

although the future game will most certainly need a 6128

Nice demo, and I like the sound of a future game...