Even more anxiety 
Only 2 question:
- we know game will be released in Cartridge format with a CPC std and Plus series adapter, is it right ?
- Is a digital version planned for emulators or FPGA systems ?
17 Likes
Again, just AI slopeā¦
:Laying on the ground crying:
1 Like
No 4 players on same screen? Give me back my money that I didnāt have yet spentā¦
Rhino really Iām speechless.
RESPECT to you personally and to all the guys that took part in this.
Starting with Batman Forever in 2011 you have really recharged the CPC community in so many ways.
Thank you!
2 Likes
The killer game is here as promised.
Thank you.
1 Like
I can only say:
wtf.
1 Like
Pending seeing it on real CPC hardware, it looks impressiveānot long now 
2 Likes
Simply stunning!
1 Like
Simply A m a z i n g !!!
1 Like
itās looking impressive, but why did you get the slopmachine to do that crappy trailer?
Thirty seconds of video - running on real hardware would have done the trick even more effectively.
1 Like
grumpy old guy gonna grump 
Not sure about World Racing in the title. Real Racing Simulator has a much nicer ring to it. And while weāre at it, why not add Gran before Vespertino? There we go! Weāve nailed it!
OMG, imagine a version on a standard Plus cartridge, full joypad control, playable on a 128K modded GX4000 
! Can you imagine?
1 Like
Interesting video. It seems to confirm my intuition.
Below my intuition and guesses. Iām not judging or trying to downplay. The result is very impressive. Bravo!
The overall strategy IMHO has two axes
Z80 has no instruction cache. Every instruction costs a lot (compared to i386 and later where instructions executed many times within a small loop are much faster). Fast Z80 code is code that has fewer instructions executed per byte written. Therefore, a golden rule of Z80 code optimization is: remove all instructions that do not write bytes to the destination. Remove (unroll) loops. Itās surprising how much you can remove when pushing such approach to the extreme. This was by exploring these ideas to the extreme that I managed to write Sunny Day (for A Shadow Party) :: pouĆ«t.net
Extreme memory-vs-CPU tradeoff strategy. Normally, the CPC has not enough memory to push the strategy to the extreme. If you have an external ROM as big as you want, you can go even further. Details below.
Details
Pixel peeping the video frame-by-frame reveals that cars are drawn with byte granularity. Width extends left an right by jumps of two pixels. When one of those is unwanted itās grey. Invisible on the grey sections of the road. Visible elsewhere. This makes simpler and faster drawing routines: just write bytes, no mask no bit handling.
Still, an extremely fast drawing routine is needed. Apply golden rule above.
If the car doesnāt move up or down (player car in particular), the routine is even simpler and faster.- Push those choice to extreme lengths, whatever the cost in storage. This is why this works only with a ROM cartridge. Huge (read-only) areas are needed.
The huge rotating cars in the selection screen is simple delta compression. Most pixels donāt change and changes are known in advance, which makes the thing very fast. When you have lots of ROM bytes available just do that. Again similar in Sunny Day (for A Shadow Party) :: pouĆ«t.net where the actually written set of bytes is n times smaller than what it seems (IIRC n=6).- All animated things are drawn with āgraphics-as-codeā. Drawing does not call a generic ādraw somethingā routine given some specific āsomething dataā. Instead ādrawing somethingā means calling a specialized routine (e.g. one routine for each car in each specific orientation, one routine for each object at each distance). Routines are pre-generated Z80 code, conceptually very simple, just write bytes, no loop no nothing. (Technique is not new, has been used in a number of prods. I did this for the level transition goodies in Just Get 9)
- A giveaway for the āonce you assume a huge ROM is available, itās okay to have huge ROM needsā strategy is the number of views of each object. In the video the authors claim 5000+ sprites. Once you have a zillion bytes and can generate thousands of sprites with a render of a digital model of a car, do it. The result is impressively smooth and enjoyable rendering of the 3D positions of the cars on the road.
This I guess applies to the road drawing. Have a huge list of specialized routines that just draw a fully finished horizontal section of the road. Call the proper routine for each line. It will be faster than the already fast Chase HQ which draws rough sections then refines for the white lane lines. This is of course more complex than a repetitive pattern like in Sub Hunter, yet that game shows that huge areas of the screen can be animated smoothly by actually writing (pushing) bytes.- Also double buffer but not for the whole screen. A full overscan screen is 24k of useful bytes. With specific settings of the CRTC and maybe some screen split, those 24k can be āpackedā (leaving the rest of the memory not too fragmented). Two buffers means 48k. A full swappable 16k area for bank switching remains. You bank switch the zillion pages to access the physical ROM in the cartridge. Even the code can be replicated in ROMs.
Andā¦ Iām not 100% sure this covers all. Maybe (probably) there are more secrets.
3 Likes
Thank you very much for your words!
1 Like
An interesting analysis, I wonāt say whether itās accurate or not!
But I have a questionā¦ In these types of games, the width of the road is usually much greater than the width of the visible screen, since the road shifts as you move laterally. Would the routines youāre proposing, which draw each horizontal line, render only the visible area? if so, how many routines would be required for each horizontal line to achieve horizontal pixel scrolling? Thanks!
This is absolutely beyond mindblowing. Just incredible!
Congratulations to the whole team for this phenomenal development.
Will there be any future discussions about some of the techniques used in the game?
1 Like
When I heard the game was going to be using thousands of pre-rendered sprites stored on ROM I knew it would have a smoothness of scaling and rotation that went beyond anything that had been attempted before and seeing it in motion at last, it does not disappoint. The CPC can do impressive things if you strap a lot of memory to it, but it takes a lot of work to use it well.
What has really impressed me is the amount of care and attention given to the front end, menus etc. This is a time-consuming and not always fun part of game development and it all looks as polished as can be, and with a coherent design that pulls everything together.
With this amount of effort we can only hope it plays as good as it looks. I see quite a few cars on screen at the same time which is promising. Not skimping on the opponent cars.
4 Likes
Well, you the master coder of the Batman Group, are asking me a question about coding? There must be a trick. 
And indeed, I have not done any calculation, its also why I strategically wrote āa zillion bytesā, which brings some welcome āblurā.
Okay let me think and try to answer your question. Having specialized routines that write a whole road line in all the cases would be simple (constant time, write 80 or even 96 bytes in full overscan) but would require an extremely high number of routines. One way to reduce could be to PUSH ground-color bytes from the right then call specialized routines to write the road itself, then PUSH some more ground-color bytes. This model limits somehow the number of combinations but cannot draw when the road extends farther than the screen edges on the left or right. Mmmh, thereās a further option that again limits the routine count, while keeping the overall speed fast. How about a cascading two-level table: for a given line geometry, lookup a list of shorter routines, call these routines. They have precomputed byte values to draw all the pixels and their number is much smaller. This will cover even situations where the road line extends outside the screen left and right, without run-time computation. Do I guess right, @Rhino ?
(warning, joke ahead 
) Plot twist: through the years the Vespertino teasers were faked, authors ask people on forum, gather their answers through the years until a powerful enough AI exists, to feed it the answers and get the real job. 
Just kidding. 
Letās become real again: congrats to the whole team for this impressive prod!
After all this time and teasers Iām eager to at last see and play Vespertino!
1 Like