Sporadic

When looking at or comparing early games a key point to remember is time. Back in the day, the Devs had probably less than a year to get anything substantial running etc. Then it was straight to market (give or take time for testing). Nowadays we have as much time as we want, to create whatever we like.

Yes

Something to do with edge wrap settings?

Yep, for sure. He's been a great help already. Now, where's that giant Jaguar shaped flashlight to shine into the sky....

That gives me a possible idea, thanks. (This is in RB+ though so I won't be doing any GPU coding directly)

There is a city stage, that would be an awesome idea for that I was thinking about the headlight thing, it might be too late in development now to switch to cry stuff and I'm also not sure on the size of work changing over to that. Would be an interesting thing to tinker with though. Thanks everyone for the kind words too. Looking forward to fleshing out the game portion more now, I've been tinkering with this for years now

It's been quite a while since I posted an update on this, so here goes; Changes since last update; - New full Blitter drawn road and scenery. - Bridges and Tunnels. - Jumps. - Rivers. - Manual or Automatic gears. - Rain and snow. - Moar colours. - Revs/speedo. I am still actively working on it, just been trying to get to a stage i'm happy with to share a new video. The video below shows a drive through one of the possible routes. Please keep in mind that all art/sound assets are still placeholders and the tracks are all under construction.

Sounds like the black border is then clearing the image away (smearing black pixels) behind the image as it goes, so self clearing. Well thought neo

Mine arrived today, thanks Albert

Zero sound engine doesn't support mod files. You're better off using an MP3 or wav and then in RB+ tell it you want to use muLaw in the assets txt. It sounds great even at lower frequencies.

Making great progress I've not had chance to look at your code/ROM but it sounds like you're doing well.

An SD cart is being worked on, but you can also get Skunkboards again. Search AtariAge posts and you will find plenty of information about them. https://www.sellmyretro.com/offer/details/skunkboard-flash-cardridge-for-jaguar-27561 They are great for development purposes.

I have had (on some computers) VJ run slower when using Zeropad. It's usually fine on real hardware.

If you change to zerosquare audio engine, that also means the input changes too. Look in quickstart document for the different constants to use and also you have to call zeropad() Both audio engines also control their own input

Yes there were some commands added to help with this. The most helpful will be powaset. This allows you to pass an array of values and it'll update all the objects at once. This is much faster than doing them individually. So for example you could have an array of xpos[60] and update those values in your code. Then pass that array to powaset with sprite_x and it'll update all those objects. You can use this for all object properties (have an array for each). Alternatively you can use the blitlist functionality and draw with the blitter. There is an example for this in rB. If you are going to use that then I recommend reading about the Jaguars Blitter first. I have some resources I can link you to later but they aren't hard to find online. I can provide more information but I'm busy at the moment but wanted to reply I also recommend looking up how to do integer math and ditch those SINGLEs. They are slow. Or create a load of lookup tables

You are checking if sfxcount > 60 there and playing the sound but not resetting the counter until 65. That will cause wierdness and call the sndplay 5 times.

I've had random sounds not play in VJ when using u235 but zero always worked in vj. Both work every time on hardware though.

Excellent work

Inactive objects are not processed by the OP. As far as I know, Raptor culls them. CJ will probably verify this

I've got my Jag plugged in to one of these through scart. The hdmi then comes from this and into an Elgato Game capture HD. Then finally into a 15inch flatscreen via VGA cable. I can't feel any lag while playing on the flatscreen (which is the main point to worry about). The picture isn't bad either. I'm not saying it's the same or better than some of the more expensive options out there but for what it costs, you cannot argue. Most of my YouTube vids are recorded through this setup. Eg. Or the Astrostorm trailer gameplay bits. I got mine through Amazon though for about £17 but as said already, there are lots of variations of this device. I didn't need to solder anything either. Edit: Something slightly annoying with it: The temporary blue overlay that states the resolution etc stays up for too long (about 15 seconds) which can be annoying if you want to start recording. This pops up whenever you reset the Jag.

Sorry my bad, I think you just want rlist[orangefish].x I can't remember where there is a list of the variable names to put on the end. I'll look later or maybe ggn has one. (It might even be in the forum or in the /docs/ install folder either in the quickstart or change log file) The rget/set version above would have to get called every frame (loop) to keep the fish moving, so yes, stick with xadd etc, it's easier.

rlist[orangefish].sprite_x = rlist[orangefish].sprite_x + (2<<16) Or rlist[orangefish].sprite_x += (2<<16) Start using rlist[] instead of rget / rset. It allows you to write the commands much easier. Your line above , using those commands should be; RSETOBJ(orangefish, R_sprite_x,RGETOBJ(orangefish, R_sprite_x)+2<<16) Which as you can see is much harder to write. Sorry I'm brief here, off to sleep now

Just had another thought; If you want the fish to keep drifting when the player isn't holding a direction then you do want to use the xadd/yadd values instead of altering the sprite_x/y values directly. Just don't zero the x/yadd values out each frame. then raptor will keep the fish moving in the direction you have set. If you use sprite_x/y (as I detailed in previous post) , you must add a value on every frame otherwise the fish will just stop moving. So it depends how you want it to behave.

I'd say, don't use DELAY(x) in your movement commands. You instead need to use sub pixel values. eg. to move 1 pixel you currently do something like; sprite_x = sprite_x + (1<<16) If you want to move 1 and 1/2 pixels per frame then you should use; sprite_x = sprite_x + (1<<16)+32768 If you want to move 1/2 a pixel per frame then you should use; sprite_x = sprite_x + 32768 The coordinates are fixed point numbers - you shouldn't need to fully understand this though for basic movement with a few pointers... The 1<<16 is your whole number (or whole pixel) - so 5<<16 would be 5 pixels etc etc. 1<<16 = 65536 (1 whole pixel) Therefore, 32768 = half a pixel, 16384 = quarter of a pixel, and so on. If you add a quarter of a pixel to the sprite_x each frame then it'll take 4 frames to move 1 pixel and hence look much smoother than other methods. There is a slight complication when using negative values. You must go to the next whole pixel value lower and then add the fractional pixel on. Eg. To move -1.5 pixels you would do; sprite_x = sprite_x - (-2<<16)+32768. You cannot just subtract the 32768 from the (-1<<16) IIRC. In the rB+ install folder and in "/website/tutorial1-2.html" you will see a larger write up about this. Now for example, you could just do sprite_x = sprite_x + 8192 when DPAD_Right is held down. This will add an 8th of a pixel on to the fishes current position and hence slowly speed up. If you then do sprite_x = sprite_x - 8192 for left, the fish should gradually slow down and then move left. This is just off my head pseudo code FYI. Hope this helps a bit...

I also noticed the original file was 16bit and the psp version was 24 bit (and larger). Perhaps this goes in line with GGNs statement above and gimp isn't filling the end of the file with zeros? Where as the PSP file is correctly being downsized to 16bit by rB+ ?