Balancing the Bus and Mastering Jaguar Performance - Tips, Tricks, Questions and Beyond - Open Discussion

[Clint Thompson]

Over the last few years, I've learned a lot about the Jaguar architecture and what you can or can't do with this environment on the Jag in general (or a result of the Jag being the Jag and not necessarily being related to only rB+). Things like setting up certain sounds/graphics from either RAM and/or ROM so that the bus doesn't implode or degradation as a result of something waiting for something else likely causing the issue(s) of said degradation. And by degradation, I am specifically referring to sounds/music quality dipping or fluctuating in tone (which is very unpleasant), screen tearing (which is the absolute worst) or anything else that affects overall performance, but usually doesn't matter nearly as much so as long as sound/music and graphics display remain unbothered.

 

In many ways, it has also increased my respect for just how powerful or capable the Jaguar actually is (like holy crap, for end of 1993 $200ish hardware, it's amazing!), despite its many faults and flaws. Yet surprisingly in many other ways, has also made me question just what they were doing or thinking in some aspects of the Jaguar hardware that doesn't make any sense at all. It's easy for someone to read the tech specs and say "But they said it could do all this!" and until you jump into creating literally anything for the Jaguar first-hand and regardless of how you choose to do that, realizing the amount of work/effort involved into making it do what they "said it could do, but not that easy Tiger!" and only then, will you truly appreciate what it actually can do and ultimately does do quite well.

 

Generally I would just keep this sort of mental discussion to myself and run out tests first hand but felt it would be good to throw out for an open discussion while also asking a performance related question, which may also clear up some misunderstandings for someone else as well on how the Jaguar handles a specific situation, should they find themselves here.

 

So... if you have a question or curiosity, maybe this thread would be a good place to freely and openly ask and/or observe without any feeling of unease. We're all still learning and even after all this time, I'm still learning and I want to continue to learn because I want to do the best that I can with my creations. The end goal is to try and maximize everyone's understanding and knowledge to obtain the best possible results for their projects on the Jaguar and from rB+ as a whole because ultimately, we all want to see great things and amazing creations continue to be developed for the Jaguar.

 

Quote

 

Q: For multiple (identical) objects on-screen at any given time, if you use the exact same object name/file (for example: REDBALL) but make multiple instances of it so that you can have 10 of them flying around for any reason:

   1. Does the Jag create/allocate an internal memory/buffer instance for each additional object OR

   2. Does the Jag use the exact same internal memory location/buffer for each additional instance all at once?

 

and if it is indeed the latter:

 

Wouldn't having the GPU/OP access the same exact file/graphic (despite the idea of saving space) inadvertently affect performance as an end result of the OP trying to access and display multiples of the same graphic from the same location as oppose to accessing different names/memory locations concurrently when it builds the display?

 

 

As far as tips/tricks go and sharing what I've personally learned (this is of course subjective and YMMV based on specific cases/needs) below are a few that work for me.

(and to give a good mental idea or outline example of my projects, I tend to use a lot of 16-bit images and animations, a mixture of 256-color 8-bit images (obviously only 1 at a time due to a single CLUT limitation) while sounds and music play simultaneously, so I definitely saturate the bus in almost all cases and it becomes a very delicate balancing act).

If you don't agree with something I've shared below, please feel free to counter with a case scenario and reason(s) as to why so everyone can better understand, including myself, because I'm far from any masterful coding Ninja and am only sharing what I know from personal experience. There are far more knowledgeable and experienced coders but here goes:

Tips and Tricks

1. Keep the scaling of objects to a minimum use or in my case, don't scale anything unless absolutely necessary. (it literally doubles bandwidth use on an already saturated bus) and while I have scaled several smaller 16-bit images (individually) without any issues (direct example: a single 48x128 16-bit image scales OK) firmly believe once you start multiplying that by any number (especially when multiple sounds are involved and by that I mean a single sound effect and a music track) issues will arise. Just remember, it's fully dependent on a variety of factors from actual graphic size (on-screen) onward. The smaller ones usually aren't going to be a problem unless it's in multiples and it never hurts to experiment so as long as you go in open-minded that it might not work the way you expect it to and that you may have to re-adjust accordingly so that it doesn't run and/or sound like garbage.

 

This is probably why a lot of experienced Jag coders advise to stay away from using 16-bit images,  however, that's not what I want to do so I'm willing to take the extra steps required to balance it in a way or manner to achieve what I personally want with the Jaguar, making sacrifices in the areas needed for the final, desired result.

 

2. Limit the amount of sounds/music you're playing in a way that sfx are not equal to or more than that of the music or in other words, keep them very simple and light. I use Zerosquare's sound player and feel that for the majority of sounds, 8khz works just fine and I only ever use 16khz for music but very carefully and only if I can do so from ROM. (I will get more into that later) but generally speaking, if your game is a cart/rom, always try to use ROM space for your sounds as it not only frees up RAM space for other things, you also avoid degradation issues when the GPU is accessing graphics from RAM.

 

3. Try to avoid using DELAYs as much as possible. Once you start adding hiccups to any major game logic, you'll quickly wreck the timing of everything else and as a result, weird side effects will show including degradation. Some things you have no choice to obviously use a DELAY for but most everything can use a counter instead. I would like to hear some examples though of how others work around this and what they feel/think is the best way.

 

4. While I'm being sort of hypocritical here and tend to use a ton of them for what I do because they're short, it is ideal to avoid IF THEN statements and use CASE statements instead, due to the way branching works and how it's an efficient direct jump to exactly what you want it to do over a laundry list of very slow and inefficient IF/ELSE/THEN statements, which can also quickly introduce degradation or timing issues into your game/project should they start to really add up.

 

5. Keep your object list to a minimum and use multiple lists if or when needed. An object (graphic) list is similar to that of an IF/ELSE/THEN laundry list, in that even if the Jaguar doesn't need to use graphics in the list from #30 to #100, it still cycles through the entire list, which is a waste of time on an already slow CPU. Excessive lists could also have severe negative side effects but generally you would never want to exceed 100 at any given time since you'll never use an entire list for a single level anyways.

Maximizing Performance Potential

To get the most out of the Jaguar, even when using a high-level language by way of rB+ (that translates/interprets your simple basic code to C with BCX/GCC) it really pays for you to fully understand the Jaguar hardware and how to take advantage of every possibility for your specific game needs. So let's take a look at our 64-Bit highway and how to get everything to where we need it so that you can potentially maximize your performance with the least amount of issues:

 

 

It's important to remember that the cartridge port is actually declared as a 32-bit expansion port by Atari in itself and should be viewed as such. I'll give a simple example of how I have personally maximized performance with minimal impact for my bus-demanding projects shortly after the following breakdown example.

 

So straight down the middle you have your 64-bit highway with TOM(GPU) branched off to the right and JERRY(DSP) branched off to the left. The 68000 is tucked away down there on the bottom left with only 16-bits of access, very limited, very slow but also very important as your game code is running on this CPU and telling everything else what to do. Right under that you have your 32-bit cartridge expansion slot that freely gives access to the 32-bit DSP and 32-bit GPU but that throughput is still limited because you have a 16-bit 68K also sharing that space/time.

 

The idea is to utilize all of these resources available that the Jaguar has to offer simultaneously in a way that benefits you.

*Please note that the below examples are not at all 100% accurate and are for illustrative purposes only, omitting things that I'm not focusing on*
I created them to give you a general visual/mental idea of what is happening and nothing more.

 

Let's say you want to play a nice, juicy but beautiful sounding 44Khz 30-second song from RAM. This is what the data bus saturation would look like:

 

The DSP is a very hungry processor and rightfully so, there's a ton of data that high-quality music and sounds use. What you'll notice is that while beautiful music will be playing through your TV speakers perfectly, you haven't even displayed a graphic image, yet you're already saturating the bus beyond the limits of what could be useful for a typical game out the gates, even in basic form. To counter that, you obviously want to keep all songs/sounds in the 8-16Khz range. Naturally there can or will be exceptions to that rule of thumb like still scene/cut scenes having little to no action but the end is still the same goal, optimization. Now, take that same beautiful sounding, bus-shattering 44Khz CD quality song and reduce it to something more acceptable like 16Khz, which is still a lot mind you because again, you haven't even added graphics or sound fx yet but now you have something that's at least manageable while still sounding good, like this:

 

 

A little more breathing room but still not quite where we want it to be.. but you know, it will work just fine as long as everything else isn't overly demanding and for most or majority of people, this will be a-ok! The above could illustrate a single 16Khz music loop OR 2 8khz samples (a music loop and a SFX being played at the same time) so you'll want to remain mindful and careful of what you're wanting to do and how you want to do it.

 

Just for fun, let's see what happens when you have a 16Khz song and an 8Khz sfx (now we're talking 24Khz total) and a full-screen static 16-bit image displayed on the screen from RAM, all taking place at the same time:

 

 

Yikes. So now you've basically saturated half of the 64-bit highway in itself just to fetch MUSIC/SOUND from the separate 64-bit RAM highway to the DSP and a single 16-bit full-screen image from RAM to the GPU. If you look at it like this, it basically leaves you with about 16-bit of throughput to main RAM but now you're starting to suffocate. You can see how little access space you have left for additional music/sfx or most importantly, graphics that require manipulation from the GPU, animations, complex movements of large sprites, etc.

 

Now let's pretend you're scaling 4 simple 32x64 16-bit sprites (which is also why it's ideal to use less demanding, less colorful sprites for animations, etc.):

 

 

You're done for. Even though you have almost 16-bits of lane space left on the 64-bit highway and have basically fully saturated the RAM access pathway but haven't technically over-saturated it yet, the second you start changing songs/sounds/graphics is when shit will hit the fan and you'll hear dipping in sounds/music or even incur screen tearing because instantly you've exceeded what the bus pathway to the RAM will allow for, which all results in possible broken audio/graphic tearing/degradation issues all-around. Of course, this isn't going to be the case with everything. As mentioned above, there are a ton of variables and factors at play as to what will break the system up but this gives a visual clue as to why it happens and how to mentally plan and counter these issues.

 

Thankfully, you still have quite a few options. You can lower the quality of the sounds, use 4/8-bit images for your graphics, use a 256-color background instead of a 16-bit image, etc. so on and so forth. Do know your limitations and trade-offs as a result by doing that however. This is especially important when you're developing a game that is being strictly ran from RAM as an .ABS or from making a burned Jaguar CD that loads said .ABS directly into RAM.

 

If you're expecting your game to be a stand alone cartridge ROM-only game, good news! You can shift some things around to increase the potential for performance, as I do with a lot of my insanely bus-hungry projects involving multiple 16-bit images, animations, music and sounds. Even then, things aren't always going to be perfect so the balancing act really is trial and error in the end but you're definitely left with more wiggle room by going this route.

 

Let's start off by shifting some tunes around to be read directly from cartridge ROM space (which is essentially the same as running from RAM but instead, going a different route on the bus altogether) with the end benefit being not only more RAM for other assets but also freeing up the bus a little for the GPU. In this example, we'll take the very same 44Khz sample in the very beginning and just place it as a cart ROM asset instead, which will then look something like this:

 

 

So while you've freed up some space to the 64-bit RAM, you're still saturating the main 64-bit highway with quite a bit of data but that little bit of shift can do wonders when you're pushing the GPU with various things. For my projects, I like to load primary music from ROM and then will load simple sound fx from RAM, which would result in looking something like this:

 

 

So I've shifted the huge data grunt of the higher quality music over into being read directly from ROM and the simple 8Khz sound fx remains over to be read from RAM, and you can see how little the impact to the RAM bus/pathway is as a result, noting that this example is just a single sound fx being played at any given time and scales accordingly. It's almost as if I've left nearly 48-bits of lane space left for the GPU/68K to access. Now let's do the same with graphics but the thing you have to keep in mind is that you absolutely cannot load larger 16-bit full-screen images or animations from cart ROM space without tearing/degradation. So what we'll do is, is load up a 16-bit background image of 320x224 directly from RAM, which will now look like this:
*As a side note, you can however load full-screen 256-color images from ROM without an issue, if your sound is running from RAM. The same applies to much smaller, less bus hungry single 16-bit image.

 

 

Finally, I will further utilize the 32-bit expansion cartridge port by loading 16-bit animations that are 48x64 and 24-frames. We are now teetering back on the danger line of a balancing act of playing it safe with any further additions because the bus has been completely saturated at this point but is still performing as expected, so as long as no drastic graphic or sound changes are needed outside of the assets that are already being used/loaded, all should remain well. So to quickly summarize, 16khz music, 8khz sound file for fx, 16-bit full color image displayed on the background, 16-bit 24 frame 48x64 animation and a few other bits and pieces here on-screen that don't really impact much results in the Jaguar's data bus saturation looking something like this now:

 

 

With my example, not only are you mostly utilizing the Jaguar hardware to it's full potential, you're basically left with about 10-15% of free bus but in reality that doesn't translate to any real useful benefit because it's not enough to keep the Jaguar purring should you add any additional sounds to be played or any other larger/moving graphics to display quickly (unless you're completely changing graphics and a delay is ok). In this particular scenario, adding another sound immediately saturates both buses of the main 64-bit highway AND to the DRAM, and as you can imagine, also instantly causes degradation issues as a result, generally always being the sound to take a hit first and foremost with more severe bus saturation also affecting the display up to the point of actually crashing the Jaguar.

 

Hopefully this write up helps visually translate why the Jaguar is as difficult as it is to not only code for but also do so efficiently, even with the most simple things and furthermore, help guide those curious and using rB+ to complete a successful degradation-free project/game!

 

If anyone notices any major errors or inaccuracies, please detail them in the thread so I can correct them. I look forward to hearing everyone's tips, tricks and advice as well so please contribute to make this thread a robust and beneficial one for everyone seeking to create the next cool Jag game.

Edited December 9, 2020 by Clint Thompson

[phoenixdownita]

I can appreciate the pictorial explanation but I don't think the Jaguar bus can be used concurrently the way you explain, I may be wrong but all the buses that I know of only allow one bus master at a time, and yes you can saturate the bus if "too much stuff goes into it" and slow-ram/slow-chips hold it while doing their accesses and stalling other chips while doing so. Usually buses cannot be partially used the way your pictures imply (16bits go here while 32bits go there etc...) and I didn't have that impression while reading the Jag HW docs.

 

[+CyranoJ]

[Clint Thompson]

22 minutes ago, CyranoJ said:

Those aren't tricks, that's voodoo.

[Clint Thompson]

23 minutes ago, phoenixdownita said:

I can appreciate the pictorial explanation but I don't think the Jaguar bus can be used concurrently the way you explain, I may be wrong but all the buses that I know of only allow one bus master at a time, and yes you can saturate the bus if "too much stuff goes into it" and slow ram/slow chips hold it while doing their accesses and stalling other chips wile doing so. Usually buses cannot be partially used the way your pictures imply (16bits go here while 32bits go there etc...) and I didn't have that impression while reading the Jag HW docs.

It was intended more as a simple graphic representation in Layman's Terms than a technical deep dive of timing, fetch and division. With that said and in the programming sense, I am able to pull music from RAM and ROM at the same time, as I do the same with graphics being pulled from both RAM and ROM at the same time. If you try to do the same thing all from RAM only, you run into serious trouble. Explaining beyond is probably buried deep in timing cycles, etc. and is far more technical than I was setting out to convey for the purpose of gaining a better general understanding on how to increase end performance and avoid bottlenecks, specifically for any newcomers to rB+

 

The real bus master!

[swapd0]

16 hours ago, Clint Thompson said:

It was intended more as a simple graphic representation in Layman's Terms than a technical deep dive of timing, fetch and division. With that said and in the programming sense, I am able to pull music from RAM and ROM at the same time, as I do the same with graphics being pulled from both RAM and ROM at the same time. If you try to do the same thing all from RAM only, you run into serious trouble. Explaining beyond is probably buried deep in timing cycles, etc. and is far more technical than I was setting out to convey for the purpose of gaining a better general understanding on how to increase end performance and avoid bottlenecks, specifically for any newcomers to rB+

 

The real bus master!

Because if you fetch all from RAM you'll have more DRAM page misses, and that means slower access.

[Cyprian]

 

really nice topic

22 hours ago, Clint Thompson said:

I am able to pull music from RAM and ROM at the same time, as I do the same with graphics being pulled from both RAM and ROM at the same time.

 

what if the DSP fetches a data from the ROM, which is e.g. 5 clock cycles (ROMSPEED)? Will the main bus (RAM) be locked for those 5 cycles for other processors?

Edited December 9, 2020 by Cyprian_K

[philipj]

I looked at "Time Sharing" at one point in time to address the bus issue... If I was to make a game engine for the Atari Jaguar, it would probably be centered around a "graphics and sound buffer" using a "non parallel" way of processing everything where each CPU would take turn using the main bus similar to old-school "Time Sharing". It's a bit crude in theory, but seem to hold some benefits like allowing each processor to have full access to all of the systems resources for more potent processing potentials, but that's just a theoretical remedy I came up with till I can get a better understanding of the Jaguar. It would be all about maintaining the graphic and sound buffers which would probably mean the use of a "double or triple buffer" situation to ensure smooth data flow for fast action playability... At least that's my game plan; I haven't tried it yet so I wouldn't advise others to do so (do at your own risk), but that's where my head has been for a while now. I know most would rather shoot for that fast on the fly real-time action, which is usually a good policy especially for real-time 3D stuff and I'm not knocking it, but given the bottleneck troubles with the "main bus", I would try my hand with the "Time Sharing" thing...

 

Now back to the topic. lol

Edited December 15, 2020 by philipj

[agradeneu]

 You can master the Jaguar with RB+? 

[Clint Thompson]

13 minutes ago, agradeneu said:

 You can master the Jaguar with RB+? 

More than you can without it.

 

It's funny though, this package (which is nothing more than a different toolset to reach a specific destination) seems to be viewed as a joke by many, but is far more powerful and useful than credit is being given. Granted, it's hard to undersell something that's literally free.

[agradeneu]

17 minutes ago, Clint Thompson said:

More than you can without it.

 

It's funny though, this package (which is nothing more than a different toolset to reach a specific destination) seems to be viewed as a joke by many, but is far more powerful and useful than credit is being given. Granted, it's hard to undersell something that's literally free.

The package is great for what it is, but only assembly coding means real control over the systems potential. 

 

Edited December 16, 2020 by agradeneu

[Clint Thompson]

1 minute ago, agradeneu said:

The package is great for what it is, but only assembly coding means real control over the systems potential. 

There's no arguing that. Of course, this thread is intended for rB+ tips and getting the most out of what it does have to offer as a package. With that said, I would go as far to say it's entirely possible to create things that far exceed the quality/entertainment/fun factor over the majority of commercial releases that came out of Atari. They used assembly, not sure what went wrong lol

[agradeneu]

8 minutes ago, Clint Thompson said:

There's no arguing that. Of course, this thread is intended for rB+ tips and getting the most out of what it does have to offer as a package. With that said, I would go as far to say it's entirely possible to create things that far exceed the quality/entertainment/fun factor over the majority of commercial releases that came out of Atari. They used assembly, not sure what went wrong lol

To be honest none of the RB+ games is at the level of the commercial releases. Lets be real. It's great for homebrew, but the fun factor is quite different, the standards are different.

Edited December 16, 2020 by agradeneu

[Zerosquare]

I disagree. There are several rB+ games that are more fun to play than some of the commercial releases.

[agradeneu]

1 hour ago, Zerosquare said:

I disagree. There are several rB+ games that are more fun to play than some of the commercial releases.

"some", ok, but fun factor is very subjective, e.g. some might have fun with Jagzombies!

 

No problem with the obvious limitations, but people should be more realistic about homebrews,  especially regarding that they should show off the "true" or "full" potential of the Jaguar system. There won't be another Rayman ,for obvious reasons, we are FAR FAR away to make something like that, but even a "Raiden" port would have been a fantastic achievement.

 

Even a much hated game like "Bubsy" looks fairly impressive, if you analyze how much work and coding skill it would take to make a similar, full featured platformer.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Edited December 16, 2020 by agradeneu

[Clint Thompson]

1 hour ago, agradeneu said:

"some", ok, but fun factor is very subjective, e.g. some might have fun with Jagzombies!

 

No problem with the obvious limitations, but people should be more realistic about homebrews,  especially regarding that they should show off the "true" or "full" potential of the Jaguar system. There won't be another Rayman ,for obvious reasons, we are FAR FAR away to make something like that, but even a "Raiden" port would have been a fantastic achievement.

 

Even a much hated game like "Bubsy" looks fairly impressive, if you analyze how much work and coding skill it would take to make a similar, full featured platformer.

Feel like you might be taking the thread title "Mastering Jaguar Performance" part specifically a little too literal and that its sole intent is for rB+ as in (Mastering Performance with rB+ on the Jaguar) and does not mean much more than that nor was I trying to imply anything beyond. So of course not, no one is going to be creating Iron Soldier sequels here or even at their worst, a Supercross 3D-clone (thankfully!). *Feel free to prove me wrong though...

 

But, there's nothing stopping anyone from making something similar to Rayman outside of sheer artistic vision/musical capabilities, coding skill, (maybe some luck), endless patience and free time of doing something with the end result of being paid nothing in return from a monetization standpoint. Which certainly has more to do with why you haven't seen and most likely never will see a Rayman-like game made using this or any other prehistoric tools available for that matter. Rb+ is almost perfectly suited for something like Rayman though, a 2D-platformer, so it's confusing why you would suggest otherwise.

 

It's not really fair to underestimate homebrew possibilities based on Atari's non-existent standards either, unless you're talking about the requirements of having pause, attract mode and music on/off options available in every game (all of which is definitely possible with rB+ if you're willing to take the time to implement it) because outside of that, Atari literally had zero standards other than to ship it before it's finished, not that it was apparent by their failure due to piss poor, non-AAA title games.

[agradeneu]

39 minutes ago, Clint Thompson said:

Feel like you might be taking the thread title "Mastering Jaguar Performance" part specifically a little too literal and that its sole intent is for rB+ as in (Mastering Performance with rB+ on the Jaguar) and does not mean much more than that nor was I trying to imply anything beyond. So of course not, no one is going to be creating Iron Soldier sequels here or even at their worst, a Supercross 3D-clone (thankfully!). *Feel free to prove me wrong though...

 

But, there's nothing stopping anyone from making something similar to Rayman outside of sheer artistic vision/musical capabilities, coding skill, (maybe some luck), endless patience and free time of doing something with the end result of being paid nothing in return from a monetization standpoint. Which certainly has more to do with why you haven't seen and most likely never will see a Rayman-like game made using this or any other prehistoric tools available for that matter. Rb+ is almost perfectly suited for something like Rayman though, a 2D-platformer, so it's confusing why you would suggest otherwise.

 

It's not really fair to underestimate homebrew possibilities based on Atari's non-existent standards either, unless you're talking about the requirements of having pause, attract mode and music on/off options available in every game (all of which is definitely possible with rB+ if you're willing to take the time to implement it) because outside of that, Atari literally had zero standards other than to ship it before it's finished, not that it was apparent by their failure due to piss poor, non-AAA title games.

 

 I see no indication that RB+ is "perfectly suitable" for something like Rayman. 

 As your article indicates, you are already saturating the bus with 1 static background image, 4x sprites and music.

So how you would tackle multi - scrolling big bitmaps (several screens), animate huge sprites (for player, enemies and bosses) and play music and FX, which any regular platformer would require?

Mind you, there is absolutely no game on RB+ that does that yet. So prove me wrong.

Edited December 16, 2020 by agradeneu

[Clint Thompson]

1 hour ago, agradeneu said:

 

 I see no indication that RB+ is "perfectly suitable" for something like Rayman. 

 As your article indicates, you are already saturating the bus with 1 static background image, 4x sprites and music.

So how you would tackle multi - scrolling big bitmaps (several screens), animate huge sprites (for player, enemies and bosses) and play music and FX, which any regular platformer would require?

Mind you, there is absolutely no game on RB+ that does that yet. So prove me wrong.

No games like that currently exist because all of like 5 people are even using it individually, maybe 10 at most? Why don't you give it a try? Also see: monetary compensation issues from previous post and/or time. There are so many exterior factors that are in no way directly related to restrictions by using rB+. Though I will say that AstroStorm from Sporadicsoft and his current work-in-progresses are super cool examples of what can be done, like Crumbs and NotOutrun (which are both 3Dish-like games):
 

 

 

Almost forgot about Tiles, which he made in only 10 days:

As far as my write-up, it explains the conditions being at a maximum in the beginning, reasons as to why, and ways to counter or offset accordingly to obtain better performance by the end. As mentioned, my scenario is not a typical use case or ideal for the majority of people making games. Most people will never use full-screen 16-bit images with multiple 16-bit animations layered on-top along with music, sfx, and other moving parts but I also go into detail on how I did it and why. You can get away with a lot more when doing a lot less by way of using 256-color backgrounds or lots of 16-color graphics, including backgrounds in multiples even, to do some Rayman-like platformer if your heart desired. Though I do believe I had mentioned that somewhere in my 296-page article

 

I encourage other experienced users of rB+ (like @Sporadic, @sh3-rg and @F.L) to also chime in to provide feedback and detail some of their use cases here, shedding light on obstacles they've encountered and sharing workarounds for others to learn from.

[+CyranoJ]

There is very little 'overhead' difference between assembler and basic in regard to setting up a display and animating/moving it around as long as RAPTOR is doing the animations and movement, as all that happens automagically in the GPU core.

 

Where the performance hits come from using basic are loops and game logic, although if the compiler was a bit smarter I'm sure it'd give some assembler coders a good run for their money in some optimization cases! 

Other tricky things to do in basic: Custom interrupt code and tasks that require direct hardware banging.

 

API 2.0 adds a load of features to bypass these issues (like high-speed blitter array processing) but they are not available to rB+ currently. 

[saboteur]

I'm no expert with RB+ but I can say this, if you want to code a game for the JAG then RB+ is the simplest, quickest way to get one made.

 

Just because your coding in basic doesn't mean the final compilled code is slow either, it's just a way of making complicated things easier for the layman to understand.

 

Sure your not going to make a real super optimised 3d masterpiece, but then who has the time anyway.

 

But it sure is the simplest way to get going PERIOD - you can be up and coding in under ten minutes on windows.

 

And if you spend some time going through the example projects and some of the pinned post's on this forum then you can knock up something simple and playable in under an hour.

 

As has been shown by others already, the more you use it the more you find out and the more feature rich your games can become.

 

The hardest part to making something professional imho is the artwork and audio, and for that you need someone with a different skillset to a coder.

 

So download it and try it over the christmas period ( 12 days of codemas ), you'll be suprised by what you can turn out.

 

[agradeneu]

7 hours ago, saboteur said:

I'm no expert with RB+ but I can say this, if you want to code a game for the JAG then RB+ is the simplest, quickest way to get one made.

 

Just because your coding in basic doesn't mean the final compilled code is slow either, it's just a way of making complicated things easier for the layman to understand.

 

Sure your not going to make a real super optimised 3d masterpiece, but then who has the time anyway.

 

But it sure is the simplest way to get going PERIOD - you can be up and coding in under ten minutes on windows.

 

And if you spend some time going through the example projects and some of the pinned post's on this forum then you can knock up something simple and playable in under an hour.

 

As has been shown by others already, the more you use it the more you find out and the more feature rich your games can become.

 

The hardest part to making something professional imho is the artwork and audio, and for that you need someone with a different skillset to a coder.

 

So download it and try it over the christmas period ( 12 days of codemas ), you'll be suprised by what you can turn out.

 

I agree it's a great tool for doing games, get something running very quickly and making the coding part easier. 

 

"The hardest part being the artwork and audio", well that's only partly true, there are other important things that haven't been mentioned yet.

 

For any more complex game, like a platfomer, the hardest part might be designing the levels and scripting dynamic objects/events.

For that, you will need some good tools, like a powerful level editor which also features scripting movements and behaivors of dynamic objects and all the stuff that will happen in a dynamic game world.

Thats quite a challenge, so far most games did simple loops like: move sprites, add collisions, shoot a numer of sprites, loop (e.g. JagZombies, Saucer Wars and other)

 

That would mean progamming the necessary tools and editors that could also be reused for other games.

So, if you like to make a fairly decent platformer, we are not even talking of Rayman level of quality mind you, you will need proper design tools!

 

You will need many talents, so a team that could pull off a fairly complex platfomer would look like this IMO:

 

- engine coder with assembly chops to get everything running

- design tools programmer/coder

- capable artists for world and characters designs

- creative level designer/world designer

- music and sound artist

- story writer

 

 

[agradeneu]

23 hours ago, Clint Thompson said:

No games like that currently exist because all of like 5 people are even using it individually, maybe 10 at most? Why don't you give it a try? Also see: monetary compensation issues from previous post and/or time. There are so many exterior factors that are in no way directly related to restrictions by using rB+. Though I will say that AstroStorm from Sporadicsoft and his current work-in-progresses are super cool examples of what can be done, like Crumbs and NotOutrun (which are both 3Dish-like games):
 

 

 

Almost forgot about Tiles, which he made in only 10 days:

As far as my write-up, it explains the conditions being at a maximum in the beginning, reasons as to why, and ways to counter or offset accordingly to obtain better performance by the end. As mentioned, my scenario is not a typical use case or ideal for the majority of people making games. Most people will never use full-screen 16-bit images with multiple 16-bit animations layered on-top along with music, sfx, and other moving parts but I also go into detail on how I did it and why. You can get away with a lot more when doing a lot less by way of using 256-color backgrounds or lots of 16-color graphics, including backgrounds in multiples even, to do some Rayman-like platformer if your heart desired. Though I do believe I had mentioned that somewhere in my 296-page article

 

I encourage other experienced users of rB+ (like @Sporadic, @sh3-rg and @F.L) to also chime in to provide feedback and detail some of their use cases here, shedding light on obstacles they've encountered and sharing workarounds for others to learn from.

16 color graphics would not be Rayman quality, far from it  See my other post why it is not just a matter of RB+. 

These are great examples for homebrews but somehow they just proof my point that they are not on the same level as commercial, professional games of the 90s (e.g Super Burn Out, Zool 2, Zoop...) I know, it's a quite unfair to say this, as 2 are not finished yet.

I read on social media stories about hombrewers allegedly "unlocking" the long sought "secret sauce" of Jaguar power, but really, that is simply not true. We had the "GPU in main" myth almost a decade ago, still, we haven't seen any PS1 level graphics on the Jag yet

 

It leads to unrealistic expectations concerning the level of quality we can achieve with homebrew games atm. especially with mostly unexpierenced coders and artists attempting the system.  Well, if you think a beginner with no track record could write and design a full featured platformer succesfully, be prepared for major disappointments and some development hell (for which neither RB+ nor the Jaguar should be blamed)

 

 

It's all repectable stuff, but nobody should expect  a new Rayman, a new Iron Soldier or anything that leaps what we already have  seen on the Jaguar during the 90s. 

Being humble would be much wiser and don't promise things that are unrealistic. Otherwise we will quickly enter "phillipj" territory of lofty dreams and no delivery 

 

 

Edited December 17, 2020 by agradeneu