Jump to content

Recommended Posts

Posted (edited)
On 3/23/2021 at 9:28 AM, phoboz said:

Yes, and probably also a good option for Genesis/Megadrive ports :)

 

However, no program on the Jaguar can do without the 68000.

It is the main CPU of the Jaguar, the other ones are co-processors which can only be given tasks by the 68000. So the co-processors cannot do anything by themselves, unless they are told what to do by their manager (If I got it right, please correct me if I am wrong?)

 

Usually you don't need super high performance for game logic, so in many cases the game logic is executed on the 68000. The nice thing is that it can do some game logic in parallel with the GPU, as it focuses on handling the graphical stuff at the same time. So the combination of this gives better performance than to put it all on one RISC CPU.

Yeah I think my mistake is that I am used to thinking about the Jag doing 3D games but really the 68K it has is probably quite substantial for 2D stuff. My understanding (not programmer) was that each game has to boot with the 68K but after that any of the 3 CPUs can control any component. Like I think even the DSP can command the blitter and the OP if you want it to. If you want everything to be compartmentalised if that is the right term you do game logic with the 68K, sound only on DSP, and geometry stuff for 3D games on the GPU. The reason why using the 68K is meant to slow things down is because it can only run from main RAM (can it run direct from cart without still blocking others from main RAM?) so nothing else can access it while it is working. The GPU and DSP have their own caches that they run code from (and can only run code from as well though that's something else(.

 

On 3/23/2021 at 3:46 PM, phoboz said:

Interesting, but I think the theoretical section trying to compare the performance between a RISC processor and a CISC processor (the 68000) using the benchmark MIPS (million of instructions per second) is a little bit like comparing apples and pears.

Because a RISC processor is targeting to execute one instruction per clock cycle (if the pipeline is kept full at all times), while on a CISC processor an instruction can take a variable ammount of clock cycles to execute. We also know that due to bugs, the pipeline of the RISC processor needs to be cleared, or filled with junk instructions, which makes the MIPS comparison even more complex.

So perhaps something can be gained when running a very tight loop on the RISC CPU, and the Jaguar really doesn't do anything meaningfull, but as soon as you start to use the object processor, and the blitter (otherwise you won't see anything on the screen). The bus will be occupied by these resources as well, so the question is really how much you would gain by disabling the 68000 when many other system resources still needs to use the bus?

I think these are good points. Well if you do the same job on the GPU instead of the 68K then the 68K still has to use the bus for less cycles. The other system resources that need to use the bus just get more cycles which is what you need for more complex stuff.

 

On 3/23/2021 at 4:42 PM, agradeneu said:

Why dealing with abstract questions, the proof is in the (empirical) pudding: Doom, you can't get those high FPS running the engine on the 68K. So Carmack and the other guys made a valid point I guess. 

But this was from a time when the Jag tried to compete with the Playstation/Saturn. 

So for hombrews it's not really that relevant anymore(?), most projects are totally fine using the 68K, because its still lots of possibilties to make a great game.

As long as the 68K does not slowdown the game, who cares which processor someone uses ;-)

 

Yeah I suppose the average game doesn't need to worry about it. I just got too used to thinking about Jag Vs PS and 3DO doing 3D games and thought everything had to be ultra efficient. I think I was also thinking that Jaguar APIs were something that were more likely to be produced to help people along with 3D games as that is what is the most difficult with the Jag. Apparently a lot of those low FPS jag games like Checkered Flag, Cybermorph etc all do geometry stuff on the 68K. TBH it is sort of amazing they get the performance they do.

Edited by No One You Know

Share this post


Link to post
Share on other sites

I'm going to start moving "random chat" from this thread into another one from this point onwards I think....

 

Maybe we need a "How the Jaguar actually works vs How you think it works vs Complete Nonsense" thread as well? :D

  • Like 2
  • Haha 1

Share this post


Link to post
Share on other sites
On 4/3/2021 at 2:30 AM, CyranoJ said:

I'm going to start moving "random chat" from this thread into another one from this point onwards I think....

 

Maybe we need a "How the Jaguar actually works vs How you think it works vs Complete Nonsense" thread as well? :D

I don't understand how you can "move" random conversations that spring up but jokes aside that thread sounds a good idea.

Share this post


Link to post
Share on other sites

JagStudio 1.1 has been released!

 

We are now feature complete with Raptor 2.0.20.

 

If you already have JagStudio installed, then to upgrade;
- Backup your existing JagStudio folder.
- Extract the new zip.
- Copy the new JagStudio folder over the top of your existing one.  (Obviously this will undo any changes you might have made to the example projects, but you can always copy those from your bakup).

 

Head on over to https://jagstudio.reboot-games.com for the download, online docs and details.

 

1.1 Change log;
* Added        Angle calculation and direction vector.  See example BASIC project 'calcangle'
* Added        Collision List.  See example BASIC project "collisionlist".
* Added        Z-Sorting for Sprites based on a sprite property.  See example BASIC project "zsort".
* Added        New "fader" BASIC project. Example on how to do CLUT fades.
* Added        Clock functions.  See new clocktest project (BASIC).
* Added        Raptor Sprite Shift.  Eg. rapSpriteShift(xshift, yshift, sprBug1, 3) - See project "spriteshift" (BASIC).
* Added        Dynamic object scale - See project "shootbang" (BASIC).
* Added        Simplified version of zeroPlaySample.
                      Now you just pass the start and end addresses - the length and rounding are worked out for you.
                      Eg.  zeroPlay(channel,start_address, end_address, frequency, params).                
* Added        Simple way to stop sound on a channel when using Zero player.
                      Rather than the old way of calling zeroPlaySample with 0's.
                      Eg.  zeroClearChannel(channel)    
* Updated    All documentation with some further clarity and the new functions.
* Fixed        BCX Print generating a \n
* Fixed        Fix build.bat so it creates a <projectname>.s in the build folder for C projects.
* Fixed        Fix build.bat so it can send ABS files to the JagGD.
* Fixed        Fix comment in object template for scale max to 228.
* Fixed        xdivs, xdivu, xmuls, xmulu where sometimes they would use an address register and fail compilation.

 

Have fun and happy coding!

  • Like 9
  • Thanks 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...