What was the Jaguar truly capable of?

[What was the Jaguar truly capable of?]

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.

[my start with RB+ - barbarian project- need help]

The channel is the first number of the command line ?

Yes

[large scaled objects near the top of the screen...]

Something to do with edge wrap settings?

[WIP : Nitrous]

 

I know, but I'm sure CJ could help you optimise whatever you wanted to achieve.

Yep, for sure. He's been a great help already.

 

Now, where's that giant Jaguar shaped flashlight to shine into the sky....

[WIP : Nitrous]

Perhaps there is some GPU time free to do some bitmap trickery e.g. alpha blend a bitmap or colourise a mask of pixels on the orad to have a more yellow tint.

That gives me a possible idea, thanks.

 

(This is in RB+ though so I won't be doing any GPU coding directly)

[WIP : Nitrous]

Definitely needs a streets of San Francisco route to maximise that car air time.

 

 

How about using cry mode to blend in some headlights at night and in the tunnel sections?

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

[WIP : Nitrous]

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.

 

 

 

 

[Properly Clearing Frame Buffer for fb2d Functions]

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

[New Jaguar Games Available for Pre-Ordering!]

Mine arrived today, thanks Albert

 

[my start with RB+ - barbarian project- need help]

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.

[New Prototype - Driving thing]

Making great progress

 

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

[my start with RB+ - barbarian project- need help]

Ok, thanks !

The most important is the real hardware

I have bought a jaguar but what a pity that an everdrive doesn't exist for jaguar !

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.

[my start with RB+ - barbarian project- need help]

hello

i have add zeropad, it works but in my game the main loop is slow down ( / 2 ) !

i use it like this :

basic_r_indx=1
basic_r_size=0
Input_SetNormalPadMode 
RLOCATE 0,16:RPRINT "input?"
do
	ZEROPAD()
	if zero_left_pad band Input_Pad_Left THEN RLOCATE 0,24:RPRINT "ok!"
loop

i do something wrong or is it normal ??

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

[my start with RB+ - barbarian project- need help]

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

[New Prototype - Driving thing]

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

[my start with RB+ - barbarian project- need help]

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.

[my start with RB+ - barbarian project- need help]

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.

[jaglib and DSP program offsets]

I fixed the weird glitchy lines flying off of polygons and did some cleanup, pipelining and optimization - I calculated that I get about 3,000 flat-shaded polygons per second at the moment. Not bad for my first shot at a Jaguar 3D engine! Of course, that's without Z-buffering...

Excellent work

[The (RND*command questions x infinity<<16) Help Thread]

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

[Very cheap SCART to HDMI converter: be worth?]

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.

[The (RND*command questions x infinity<<16) Help Thread]

These are the errors I get when I use either RLIST function exactly as you have written out:

 

As:

rlist[orangefish].sprite_x = rlist[orangefish].sprite_x + (2<<16)

 

error1.png

 

or as:

 

rlist[orangefish].sprite_x += (2<<16)

 

error2.png

 

and if I use this:

 

RSETOBJ(orangefish, R_sprite_x,RGETOBJ(orangefish, R_sprite_x)+2<<16)

 

I press right, it sets the fish over 2 pixels but does not continue to push the fish left or right the longer you hold the button, even though the fish was in an entirely different location. That's why I used xadd and yadd, because it would continue to roll and keep going, not just move this object a few pixels from it's current location.

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.

[The (RND*command questions x infinity<<16) Help Thread]

Now I know why I did it that way in the end. When I press right, instead of the fish moving right it completely re-positions the fish to the original rapint coordinates and then doesn't actually move right but for whatever wonky reason using x/y_add does it just fine?

 

When you say "something like this" I need verbatim for what exactly it needs to be since I couldn't get the = to work at all, so maybe that's my issue too. I tried multiple things and it just failed to compile. Sorry for what may seem obvious isn't clear to me.

 

Here is what I'm doing but it's just not right:

 

SUB right

 

RSETOBJ(orangefish, R_sprite_flip, R_is_flipped)

RSETOBJ(orangefish, R_sprite_x,R_sprite_x+2<<16)

 

END SUB

 

Should I be using something other than RSETOBJ?

 

 

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

[The (RND*command questions x infinity<<16) Help Thread]

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.

[The (RND*command questions x infinity<<16) Help Thread]

 

Right now I know you can add a delay between moves if using a sub routine but feel that may be causing problems and that there may be another command or function to use for this? That way say I press right then release, the fish doesn't come to a complete halt but slows down and then drifts even slower for a few seconds. The problem with delay is that it's only giving me the speed of the update so it's either slow at 1 or faster at 2 with no in-between or below 1.

 

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...

[Importing backgound images]

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+ ?