Vespertino - How's this being done? (speculation!)

[keith56]

Ok, so I'm sure everyone has seen the Vespertino video by now, and is suitably amazed by it... but I want answers, or at least guesses!... how's this being achieved!?



Now I'm guessing it's some kind of CRTC rupture trick, where the '3d' track is being built up in 2-4 line 'strips' which are being repositioned and warped using memory offsets and HsyncPos, but I know of no way of 'scaling' a line with these kind of tricks - or maybe I'm wrong..

Also, the players car seems to be in a constant position, which would contradict my theory, as if the CRTC registers were moving the track, then the car would move too - of course the car alone could be being redrawn... I notice the top half of the screen with the timer is pretty blank - leaving a good amount of time for data updating...

it's my understanding that the screen memory address cannot be changed midline, but maybe there IS a way I don't know? that would maybe allow for scaling effects, and the car sprite to be 'paged in'

Update: I've been looking some more at the video - I'm assuming there's some 'palette switching going on to color the track, as the grass and track seem to switch colors at the same time - I also notice there are multiple kinds of bush alternating on the left hand side, and that they seem to be on the same horizontal line as other objects in the distance (which again wouldn't work if the lines were totally 'pre-rendered')

Does anyone have any theories of how BG productions have achieved such an impressive playable game on the old CPC?... I'd love to hear them!

[fgbrain]

I am still not convinced that all this stuff runs on a plain 6128 at that speed!!!


There are no CRTC tricks I am aware of that can be applied to such kind of game....
My explanation is that double buffer screen is used and very fast drawing routines...
Totally unrolled codes  with no loops.. stack abuse ....second register set etc..


But still I admit looks unbelievably fast!!

[Targhan]

I'm by no mean a CRTC master, so I may be 500% wrong... But I believe this is a line-by-line split screen. Maybe each road line, without sprite, is precalculated and copied whenever needed. By knowing what changes, only the differences can be displayed from one line to another.

To go even further, maybe each frame is precalculated as to what "lines" of the road to display. The drawing of the road *seems* a bit limited, so the same "road patterns" can be reused through the levels.

Then sprites are added on the fly... The hardest part in my opinion!

[AHack]

To quote myself from the other thread:


"I'll make a stab at what I think 3D CRTC-FX Engine is. I think the screen is been ruptured every scan line for the road, so that you can have a hardware scroll offset for each line. The road graphics are precalculated on a scan line basis so for each screen line you set a start address for the CRCT so you don't need to copy the graphics by the CPU.In away this is mimicing what the Amiga COPPER can do and these types of games were done this way on that system. If you look at the road in the video the top part of the screen is where the game will calculate game logic while the road area will need exact timings to manipulate the scan lines. The mountain areas is a bigger screen ruptures so the mountains can scroll left and right. And the up down movement is a combination of vertical scrolling or changing the addresses for the scan line ruptures. That's my guess  "

I do agree the hardest part will be overlaying sprites over the split scanlines.

[AHack]

PRI, I think is Programmable Raster Interupts which will make the managing of the line splits easier.


UFD, there's a thread on that already if people are interested.

[AHack]

Actually the sprites may not be that hard to do. If the road uses pre-defined strips of graphics that can be hardware scrolled left and right then you have something to draw in. So, I guess for each line of a sprite you blast it to the pre-defined road strip using UFD. So all you need to do is match a sprite line to a pre-defined road strip. In a way you break sprite drawing into scanlines. Sprite routines work this way anyway. The difference is instead of calculating the next screen address you calculate which scanline you should be on.

[fgbrain]

Keep in mind that overscan is used... So even slower routines for screen addressing!!


Again about line splitting.. Its not possible to display sprites on top. Perhaps on a cpc plus its  doable only...

[TotO]

Keep in mind that overscan is used... So even slower routines for screen addressing!!

The "road" Area is less than 16k.

[AHack]

Looking at the video again, I think this is how it all works from my above posts. If you imagine looking down a straight road in perspective and have those scanlines pre-defined, maybe have a few different types to add variation to the road texture, then you start playing around with scroll offset you can fake the road going around corners and with the variation of the pre-defined lines you can fake road movement. The up and down bit of the road can be faked by altering the lines that form the perspective to different scanline positions. Anyway, all speculation but thinking about it I would do it this way. I basically did effects like that on the Amiga using the COPPER a lot of years ago. In a way Rhino is sort of emulating the Amiga COPPER for scanline manipulation.

[AHack]

Keep in mind that overscan is used... So even slower routines for screen addressing!!


Again about line splitting.. Its not possible to display sprites on top. Perhaps on a cpc plus its  doable only...

I think it is. Your pre-defined road scanline is Destination and your sprite scanline is Source. You just blit the source with UFD to the destination.


Then because the CRTC line split can set a hardware scroll address then you don't need to copy the line with the CPU. I can see have all this works now.

[AHack]

The sprite scaling of bushes and other road furniture would be easy to do with ths system. Vertical scaling is free because  the CRTC is working on a scanline basis for the road. Horozontal would have the be pre-calculated for the different scale sizes.

[AHack]

If you have enough memory then background restore of the pre-defined road strip can be quick if you have 2 copies of it... one for drawing on and the other one to restore it.


So you would UFD the sprite line into the pre-defined road scanline and let the CRTC display that line. All you need to store is the start and end position of the sprite line in the pre-defined road line, then all the restore has to do is UFD the copy back to line strip you have just drawn on.

[AHack]

Yep, the secret to all this is that the CRTC can set a screen address for each line which is basically doing a free copy to the screen. And from there it's just choosing the right pre-defined road scanline to draw a sprite scanline into.


From that basic concept you can see how a game like this is possible on the Amstrad. If it was not for the CRTC and the free copy, by choosing the screen address, then it would not be possible to do this.






Edit. Saves creating a new post.


Because the CRTC is copying for free then any pre-defined road line that has no sprite lines copied into it gets displayed with very little CPU overhead. The bulk of the work is copying in sprite scanlines into road scanlines and restoring them. The top haff of the screen with the mountains is a bigger screen ruptures to scroll - that's all pretty basic CRTC stuff there.

[keith56]

Thanks for all the comments, I find trying to think this one out fascinating!

AHack's comments seem to be pretty much what my current theory is... but if anyone else has any other ideas, please let me know!

Oh, I watched the video again in slow motion - I notice there's two different kinds of 'green bush' alternating in a single road strip on the left - that kind of attention to detail is crazy!... I'm guessing the reason the bushes and other road objects change occasional is new ones are being transferred in from ROM into RAM so the level appearance changes as the track progresses

[roudoudou]

Keep in mind that overscan is used... So even slower routines for screen addressing!!

You mean FASTER routines since there is obviously NO overscan in the game (overscan IS NOT fullscreen*)

Basically the road display is kind of linear data plus road shape as additionnal shift & jump between lines

*and the game is probably not fullscreen either 

Again about line splitting.. Its not possible to display sprites on top. Perhaps on a cpc plus its  doable only...

Done in 1990 by Overflow in S&KOH. Should be possible to do moar without on the fly computations? 

[fgbrain]

IMHO it doesn't look like it uses 32char. screen.
Its so much wider which means using 16bit additions instead of say INC L...

Besides if they managed to draw that many sprites over a line splitting... then it's a new revolution!!

[roudoudou]

IMHO it doesn't look like it uses 32char. screen.
Its so much wider which means using 16bit additions instead of say INC L...

Besides if they managed to draw that many sprites over a line splitting... then it's a new revolution!!

you can use INC L with a screen of 256 bytes wide -> 2048 mode 2 pixels, 1024 mode 1 pixels or 512 mode 0 pixels
a borderless screen can't be wide than 192 mode 0 pixels so....  -> INC L can be used anywhere when line splitting

but look at the bushes and kind of JPG macroblocks, the sprites are PUSHed so no worries 
yeah, it's kind of revolution to draw many sprites over line splitting. Really cool !

[fgbrain]

you can use INC L with a screen of 256 bytes wide -> 2048 mode 2 pixels, 1024 mode 1 pixels or 512 mode 0 pixels
a borderless screen can't be wide than 192 mode 0 pixels so....  -> INC L can be used anywhere when line splitting

sorry but you are wrong... using only 8 bit commands say INC L will result to wrong screen addresses!!!

For example, on a 48 char. screen (overscan) third char. line goes from &C0C0 to &C11F
its clear you need 16bit additions!!

ONLY in a 32char screen the screen addresses are page aligned!!

[Longshot]

What Roudoudou is telling you is that you can change the address of each character line so that only the low byte of the video memory address changes during this line.
Besides, you do not have to change the address of each character line.
Just choose wisely the size of your line to minimize the cases where there is an overflow.

And for the line or lines where there is an overflow, you can plan a different routine to increment your pointer ("inc hl routine" instead of "inc l routine")

You can also try to figure out how to position your screen so that the addresses that need an "inc hl" are positioned in areas where you will not display anything.

[roudoudou]

sorry but you are wrong... using only 8 bit commands say INC L will result to wrong screen addresses!!!

For example,  blablabla

Sorry but you're wrong
1/ you do not need overscan to fill all the screen
2/ using line per Line mean ALSO choose adresses that dont need 16 bits INC


As longshot Saïd
Technic is one thing
Wisdom another one 

[fgbrain]

Ok now we agree but then by skipping those lines screen gets smaller and code more confusing.....
Besides if they're using R9=0  the game won't run on CRTC type 2.


Longshot thanks for clarifying this.
BTW what's your opinion about the game engine???

[AHack]

Ok now we agree but then by skipping those lines screen gets smaller and code more confusing.....
Besides if they're using R9=0  the game won't run on CRTC type 2.


Longshot thanks for clarifying this.
BTW what's your opinion about the game engine???

There's a technique called RVI that will allow it to run on CRTC type 2. I've been trying to find information on it. I found a French forum that explains a bit about it - but using Google Translate is not ideal. Does any expert want to explain how this all works?

[roudoudou]

As the CRTC-2 cannot split line per line you may add an short split at the end of the line (without an extra HBL)
Then CRTC-2 may split on visible screen line per line

[AHack]

As the CRTC-2 cannot split line per line you may add an short split at the end of the line (without an extra HBL)
Then CRTC-2 may split on visible screen line per line

Is there some simple code that can show this technique working?


I presume you need exact timings at the end of the line for different CRTC types?


I presume losing the HBL at the line end causes a sync to happen which in turn makes the split happen.


Rhino did memtion about his PRI (progamable raster interupts) that you could do it 2 ways and one was more complicated to do. So I'm guessing here that by forcing a sync at the end of a line would also reset the interrupt counter? He also mentioned about filling in constant time for useful things to do in those interupts to stop dead cycles. So guessing again he probably uses the raster interrupts for waiting for the end of the line.

[Longshot]

Besides if they're using R9=0  the game won't run on CRTC type 2.

There's no interest to modify the address of each scanline if you want to avoid "inc hl".
You just need to modify the character address. So you don't need in this case to set R9=0.

BTW what's your opinion about the game engine???

The images I saw on the promotional video indicate that there has already been a lot of work.
I think there are dynamic splitscreens that show the exploitation of the crtc.
The engine is fast and I think the stack is hugely solicited for the displays.
I think it is always a good thing when the resources are well exploited.
I expect to see the playability of the finished game, with the other vehicles and the sound effects.
I hope this project will go to the end because finishing a game is also a big workload.

There's a technique called RVI that will allow it to run on CRTC type 2. I've been trying to find information on it. I found a French forum that explains a bit about it - but using Google Translate is not ideal

RVI is a French acronym for "Rupture Verticale Invisible" (Vertical Invisible Rupture)
This technique was imagined and applied by Overflow in its "S&KOH" demo in 1991.
It consists of creating small screens in the "invisible part of screen" to change several times of block, in order to choose the block displayed on the following line.
One method consist to change R0 and R9 to do it. Small screens can last 2 nop (for example R0=1 for 14 nop (in the "invisible" area of screen), and R0 = 49 for 50 nop in the visible area).
This creates an interdependency between the lines to be managed. But you can imagine others funny methods to succeed.
Of course you can also make visible splits in the middle of the screen. (However, on some crtc, a small border area appears between each screen)

I presume losing the HBL at the line end causes a sync to happen which in turn makes the split happen.

You make a confusion between synchronization and construction of the image.

The CRTC has several registers and counters to build the image.
In general, when these counters return to 0, the transition causes the management of other counters and registers of the circuit.
In particular, taking into account the memory address present in R12.R13 of the crtc (the "split")
Preferably, each line must be 64 nop and the screen consists of 312 lines.

The CRTC must, however, generate an image that conforms to the standards of the monitor.
To synchronize this image, the monitor relies on signals generated by the CRTC.
For the vertical position it is R7-CRTC for the character line or the VBL must occur.
For the horizontal position it is R2-CRTC for the position of the character where the HBL occurs
(and R3-CRTC for its size (this can be used to shift the scren with 1 byte instead of 2)).
It is not advised to move these sync areas from one line to another.
Except if you want to obtain an analogical deformation of the image (this has been used by many demos)

If you generate several HBLs on one line, the monitor may have trouble knowing which hbl to use to stabilize the image horizontally.
However, by reducing the size of the "visible" HBL, you can easily generate several hbl on one line.
This is useful, for example, if you want to change the graphics mode multiple times per line (then hbl size must be 2 nop, which is the min delay for the gate array to succeed).

PRI is an acronym used on Amstrad Plus to define the register that defines the precise line on which a raster interrupt should occur.
In general, the interest is to reprogram an interruption from the previous one.
On CPC OLD interrupts occur on the basis of 2 counters, and every 52 hbl (C32 + C20).
When an interruption occurs, the counter are not affected.
But when the 2 counters have finished their count, an interruption becomes pending.
In general, with 1 hbl per line, you have to wait 52 lines for an interrupt to occur.
If you want an interruption to occur "earlier", you need to generate several hbls on the line or allow a first pending interrupt on hold manually (ei).
In the latter case, it is necessary to pay attention where the pending interrupt is acknowledged.
Because if it occurs while C20 is counting, then the acknowledgment for C32 is cleared, which results in a shift of 32 lines.

So to define an interruption that occurs before 52 hbl, you have to sacrifice time and display.
Conversely, you can delay the moment when an interruption occurs (thus more than 52 hbl) by resetting the counter (via the gate array).
You can also simply acknowledge or allow interruptions where you want.