forum.defence-force.org

What do guys think about the idea of porting Crazee Rider to the Oric:

https://github.com/KevEdwards/CrazeeRiderBBC

.. too difficult, not worth it? Better to re-write?

I'm absolutely not familiar with the BBC Micro, but from what Wikipedia shows: it will be not easy for porting

I've always been keen on such "road race" games on Oric..

Games like pole position on atari, has such "road turning" animation and its a nice challenge for Oric.

As far as I know, there's no such game but one : "Starter 3d" which has really neat road animation effect but playability is really hard. But road animation is admirable. I don't know how they could manage to do it.

Apart from this, I think there's no other road race game with such animation. But starter 3d prooves that it is doable.

Wow... I didn't know the "Starter 3D" game, I tried it and yes, it's definitively the best ever 3D rtacing game on the Oric on the technical side !!
Unfortunately, it's quite unplayable, I was unable to pass the 2 qualification laps, and you don't even know the maximum lap time to get qualified... I tried the keys to tighten the turns in order to increase turn speed, but it's too complicated because you then need to handle 5 keys that are awkwardly placed..

Anyway, back to the original subject, I suppose Crazee Rider can be "ported" as long as you understand it will require some compromise on the graphics/animation side and maximum number of animated objects on screen... Also, it will certainly require 100% assembly code, as compiled C code will certainly not be efficient enough...

In any case, you can have a look at the original code to maybe get an idea about how it's done and possibly reuse some code, but it will require a total rewrite for the Oric as there's no similarity with the BBC as far as graphics are concerned...

The easiest form of road animation is probably the "night driver"



I don't know how they calculate the movement of road . Maybe sinus tables ?

Hmm... I kind of feel that 3D Fongus is a kind of a 'better' example of this kind of game, given that it has a lot more action going on .. gotta love those rhino's, LOL ..

Well, I wasn't including 3D Fongus in the "3D racing category" although this point can be argued of course, because you can race planes as well as you can race cars

Anyway, I totally agree with you, 3D Fongus was probably the most impressive 3D game on the Oric, and was in addition one of the most enjoyable and well-crafted games ever released on the machine !! I spent hours playing it, very fond memories indeed !!

My interest is in how the scrolling was done so rapidly .. I'm working on an app for Oric which requires this kind of smooth scrolling (though for different purposes) and so going through all these examples, I'm trying to grok what's going on .. these scroll routines are fascinating.

Well, you could disassemble the game, or trace the code in Oricutron's debugger

Examining the code, I see that every road animation is drawn with character definitions. I thought it was calculation of sinus arches . They probably create every road turning possibilities . Incredible..

I interviewed 3D Fongus' author years ago. He explaiend that for the animation, the "sprites" were stored as vectors and re-drawn in memory after loading (when the game says "codage en cours"). They are drawn at all possible sizes so he just has to swap bytes to display them fast.
He said the inconvenient was that it meant 6 pixels steps in animation (size of a displayed byte), monochrom and with some coulour clashes, but that was very fast. He dropped the idea of converting the game to Amstrad as it didn't have such trick to display groups of pixels.

See, this is the fascinating part .. unrolling all of these plots down to character arrays for blitting .. I definitely need to learn how to do this.

Interesting technique although I am willing to bet a few live kittens that it probably would have been much simpler to write that game in HIRES mode.
Racing/driving games which use raster based road driving are actually playing to the strength of the Oric, especially the serial attributes since they rely on drawing lines consisting of large solid blocks of pixels, something which is very easy to do with serial attributes.

Drawing vehicles and roadside objects on top of that adds a bit to the complexity but in my opinion not too much, especially if using an alternate line mode where moving objects are drawn on even lines and the road + background are drawn on odd lines.

One of my Oric projects is actually a raster based road drawing routine but I must finish my current one before I start this one.

My mind is confused on step of giving curve to the road. Calculating sin waves? bezier lines?

I read many sources about race game road making and I can't imagine still how they do it, especially under limited power.

Some of these sources are ;
https://codeincomplete.com/posts/javasc ... v2-curves/
http://www.extentofthejam.com/pseudo/

As far as I understend, they build the road with scrolling blocks. In atari they have HMOVE command to move horizontal lines or objects.

I couldn't imagine how to do it with Oric.

It can be applied by drawing predefined curved roads, maybe step by step but it can't be as smooth as pole position, enduro or even night driver..

So, they do it with starter 3d years ago.. It means its doable.. Maybe much easier way but how, I don't know

I guess one of these days I'll have to finish convert to assembler my old C prototype:
http://osdk.defence-force.org/index.php ... &ref=ART11