Sporadic

I use psp7 with zero issues. Reinvent the wheel? No thanks lol

Small tip: don't disable the first or last objects on the rapinit.s list. Just saying, in case that's what broke yours.

I'm talking about anyone developing for the Jaguar now, not modern commercial game developers.

It would be good with a mouse but I doubt it would get added I'm afraid

Also, anyone developing now can take as long as they like. I'm sure anyone programming for the Jaguar back in the day had very tight deadlines in comparison.

Not a bad idea, I will give it some thought. I do kind of like the blocky look though for whatever wierd reason :/

Here's a more up to date video showing the new UI I've been working on

It sounds like you must have one/some of the object settings wrong for that one in the rapinit.s And yes, anim is bottom to top

Actually rlist[sprTitle].x - ((RND*5)<<16) might not compile. It might think (RND*5) is a float, which you can't then use <<16 on. So you might need INT(RND*5)<<16 or cast it ((INTEGER)RND*5)<<16 Have a play - that's the best way to learn. Or most fun at least.

Using RND at runtime will cause slowdown. I advise creating an array and filling that with random values before the game starts. Then while the game is running, just incrementally loop through that array to get the next 'random' value. When you reach the end of the array, go back to the beginning. Perhaps start with just 10 values, you can always increase the array size later. Also, don't use FLOATS as they are slow. Store the RND values as RND * 100 (for example). This will give you a value between 0 and 100 depending on what RND returns. Rather than between 0 and 1. Then, say you have a variable declaration in your code for the title screen such as ; DIM sprTitle AS INTEGER : sprTitle = 0 While looping you can do something like; randomvalue = rndarray[counter] if randomvalue < 50 then rlist[sprTitle].x = rlist[sprTitle].x - (5<<16) else rlist[sprTitle].x = rlist[sprTitle].x + (5<<16) endif If you don't know what the (5<<16) is, RTFM or RTFwebsite. Basically it's scaling the number 5 up to 16.16 fixed point. Just change the 5 if you want to move it a different amount (for now). You can expand on the above code to change the y coords too. Also, that doesn't check any x or y movement limits so in theory if you had a lot of consecutive values less than 50 then the title image would move off the screen to the left. Finally, a free gotcha, don't try and disable/hide/R_is_inactive the 1st or last objects in the object list. So you might have to create a small off screen dummy object as the 1st object when you come to hiding the screen. I hope that gives some clues, I kinda just brain dumped.... EDIT: Of course, for starters you might want to just do rlist[sprTitle].x = rlist[sprTitle].x - ((RND*5)<<16) in a loop to see stuff happen. Then worry about optimisations. EDIT 2: Don't forget to include a VSYNC inside your loop. You'll see this in most of the examples.

Here's a quick 16-bit title screen example. Notice there is ZERO .bas coding in the 16bit.bas file (apart from the print commands). This is because the object is defined and displayed via the rapinit.s object list file. The assets.txt defines where the image is and what to convert it to. To create the attached image i opened it in Paint Shop Pro 7 converted to 16 mill colours 24 bit and saved as a BMP. rB+ then converts that to 16bit during the build. Hopefully this will help as a starting project. Make sure you read the rapinit.s and ALL the params for an object. What you should do next is create a variable in the .bas that points to SPR_TITLE and then you can use that variable with rlist[varname].rapinitprophere to manipulate it. Such as rlist[varname].active = R_is_inactive to hide the itle screen. Remember you can have a mixture of colour depths on the screen, so small sprites could be 4 bit to save processing power (for example). But then you have to use CLUTS etc. 16bit rB+ Demo.zip

Is checkered flag alpha Vs the final game a good analogy here?

Yes, that's a very good resource and an interesting read for those interested. It seems to be the most used example. Unfortunately not a cut paste job to get working on the Jaguar though. The source code I'm running is very different to the code I started with.

As a video finally exists, I thought i'd add it here

I thought it would be nice if people could see this in action. CJ has very kindly recorded a video for me using his Elgato. Remember the graphics and sound are still placeholders and the tracks are under construction (so some are quite short at present). Change list; -Fixed big hill slowdown. -Fixed clipping on hills. -Fixed janky road line. -Fixed jumpy scenery on checkpoint. -Fixed delayed horizon scrolling. -Added Stage map (top right) - updates as you change stages. -Added Stage names before split for left / right. -Added some basic layouts to all stages. -Added more palette switching for stages. -Added road crossings (no collision yet and they are too frequent). -Removed music temporarily.

PM Albert with details

I will probably release an updated binary at some point (hopefully not too distant future). I really want to get this finished asap so I can move on to a new Jag project.

Still ticking along here... I have plumbed in the course map (top right image) and worked out the 15 stages which i'm in the process of creating. Here's a quick screenshot of a new feature I just added; Road crossings! (aka, more stuff to dodge). This may or may not make the final game - it depends if they are too annoying. It could be a feature for the later stages though.

You should add the ability for users to import their own roms/art/manuals. That way if someone has something they play that isn't on your list then they aren't restricted to your list of 41 titles etc.

I'm sure they aren't telling you that for your own good. Basic is a great place to start for a new programmer, as a programmer myself, I'd never recommend assembler to a beginner. Raptor Basic still has some advanced elements (compared to normal basic) due to the nature of the old hardware but you would have a much clearer understanding of what's going on by using it.

that looks identical to my order (except the postage)

The documentation, examples and website are your friend. Go read and digest, you'll gain a much deeper understanding. There are various things to set up with regards to colour depth so will be easier if you have taken all that in.

Perhaps try 16 bit or 8 bit. You probably wouldn't notice much difference. I don't have my pc handy to count the number of colours in there but I doubt it needs to be that high. Also, that sprite is roughly 1/3 of the screen width, does it need to be that big? Not sure about your question on if raptor will handle lower than 24bit? It handles lots of bit depths and all your graphics can be different depths.

That's a kind offer, thanks. But I couldn't accept. I have been planning on making one though

Thats possible and could be interesting to try. Id need a rotary first though. ...