How was the object processor used?

[VladR]

and let the GPU render a high-poly version to screen using a type of scan-line render-er using the OP. Or if I could just fake the living daylights out of 3D using 2.5D methods at the GPU level based on the real low-poly 3D stuff, I'd settle for that; the Jaguar's strength is in it's 2.5D rendering.

Scanline Renderer ? This is wireframe of a proper 3D scene. There's no scanlines, just lines from point A to point B. OP won't be of any help with that whatsoever.

 

Blitter will, however. You run the loop on GPU, where you transform 2 endpoints, spin the sucker up, and then without waiting for it to finish, go transform another batch of vertices. Only then wait (or sometimes not, as if it was short line, it already got rendered in parallel for free).

 

 

using 2.5D methods at the GPU level based on the real low-poly 3D stuff, I'd settle for that; the Jaguar's strength is in it's 2.5D rendering. I've always been a firm believer in that fact.

Where do you see 2.5D there? The objects even rotate along all axis. It's full 3D, just the camera - for the sake of gameplay - is on the rails.

 

 

There's a hard limit how many times you can spin Blitter up at 60 fps. Even if the lines are 1 px short, that limit is there. So, much much sooner than you think, you'll hit a concrete stone block, and no amount of splitting the work among 68000 and DSP will help you.

You could, of course, do SW rasterizing in parallel on both DSP and 68000. The DSP's 16-bit bus won't matter, as you draw lines byte by byte, so it's going to 8-bit access anyway.

The problem is, however, that you'll be hitting and locking the bus from 3 places : Blitter, DSP, 68000 and while the grand total number of lines drawn will be higher (than it would be from just GPU), when using all 3, just don't expect a dramatic increase in number of lines at 60 fps.

 

Obviously, if you're willing to drop down to meager 30 fps, or god forbid, even 20 fps, of course, you can multiply the total line count accordingly. And, if camera doesn't move very fast, 20 fps is ,indeed, still doable.

 

I did some similar-looking experiments. This particular one is not using Blitter for lines - just drawing them pixel-by-pixel from GPU:

 

https://www.youtube.com/watch?v=LEOCtm_aotg

 

So, you can expect a similar output from DSP (again, from GPU, I was doing 8-bit access, so the DSP's 16-bit is more than adequate). Of course, minus the bus lock, as when the GPU is accessing framebuffer, the DSP has to wait, and vice versa.

 

Using GPU to draw lines pixel-by-pixel gives you a tremendous advantage in the visuals, as Blitter cannot do the shading at 256 color mode.

But, on GPU, you can do it very easy (note the colorful lines):

https://www.youtube.com/watch?v=ahx9_hNm0So

 

At some point, I would like to redo the scene by incorporating a second thread from DSP, third using a Blitter and fourth just simple line drawing via 68000 - basically banging on the bus from every single chip in the system (OP:reading the framebuffer, Blitter:drawing lines, DSP: Drawing lines, GPU:Drawing lines, 68000: drawing lines).

 

This kind of test would show the breaking point of concurrent bus access - there's going to be a threshold where adding a single additional line would result in dramatic slowdown, as all chips are accessing same area of RAM. One of these days...

[JagChris]

He's aware that it's polygons. You gotta slow down a little in your reading my friend. ?

[LinkoVitch]

OK... Here's a good example of a low poly engine running an X68000 computer... It's very fast with no surfaces, just straight wire-frames running decently fast on a 68k processor. For the Jag, I would use low poly using the DSP, or the M68k, or both for speed and let the GPU render a high-poly version to screen using a type of scan-line render-er using the OP. Or if I could just fake the living daylights out of 3D using 2.5D methods at the GPU level based on the real low-poly 3D stuff, I'd settle for that; the Jaguar's strength is in it's 2.5D rendering. I've always been a firm believer in that fact. That's my vision a 3D engine for the Jaguar in a nutshell.

 

 

Honestly, the best bet would be to use the GPU to do it's job as intended, performing the vector maths calcs and feeding work to the blitter. Use the blitter to build the output in a frame buffer, and then once drawn, point the OP at it. You don't have any risks of a single scan line being too complex and taking too long messing the whole thing up that way, you only show a frame when it's ready, and you get no tearing when there is movement.

 

Us the OP and blitter as they were intended too, the system will work with you then, not against you. Use the 68K sparingly if you don't have the bus time, or as a manager for your game, leave the DSP for all the other bits and bobs, or even use it as the main system loop and bin off the 68K.

 

But don't try rendering your 3D scene into the scanline buffer 2600 stylee with the GPU, there be dragons, headaches, and an ultimately sub par result. The jag can do 3D, same as significantly less powerful systems could do in the late 80's.. Jag can do it better I am sure and faster, until you start trying to treat it like a modern system (which don't forget is 20+ years it's junior, and computer tech increases in performance exponentially).

[VladR]

He's aware that it's polygons. You gotta slow down a little in your reading my friend.

Granted, it was 3am here, and I was sleepy&grumpy, but he mentioned 2.5D, like, 2-3 times.

 

2.5D is largely accepted as isometric engine - e.g. Diablo. Whereas in that x68000 game, it's a wireframe of a proper 3D world...

[philipj]

There's a hard limit how many times you can spin Blitter up at 60 fps. Even if the lines are 1 px short, that limit is there. So, much much sooner than you think, you'll hit a concrete stone block, and no amount of splitting the work among 68000 and DSP will help you.

You could, of course, do SW rasterizing in parallel on both DSP and 68000. The DSP's 16-bit bus won't matter, as you draw lines byte by byte, so it's going to 8-bit access anyway.

The problem is, however, that you'll be hitting and locking the bus from 3 places : Blitter, DSP, 68000 and while the grand total number of lines drawn will be higher (than it would be from just GPU), when using all 3, just don't expect a dramatic increase in number of lines at 60 fps.

 

@VladVR

I remember some years back I had a discussion about the Jaguar's ability to do "Parallel Processing" and from that discussion it became very clear that the Jag bus bottleneck issue will probably require a less parallel technique to getting over the bottleneck issues... Not that it isn't possible, just a bit of a nuisance and potentially problematic towards progression so I've always bear that in mind; I think that whole discussion started from my curiosity of why "Checkered Flag" ran so sluggish on the Jaguar. It was assumed back then that the M68K was hitting the bus too hard doing a lot of game logic and AI functions thus is why I was a bit hard on keeping the 68K off back in the day. A less or non parallel way of processing would probably mean a less or non traditional method of real-time graphic display in a meaningful way. That's where my head is for Jag development.

 

 

Granted, it was 3am here, and I was sleepy&grumpy, but he mentioned 2.5D, like, 2-3 times.

 

2.5D is largely accepted as isometric engine - e.g. Diablo. Whereas in that x68000 game, it's a wireframe of a proper 3D world...

 

It was my understanding that the phrase "2.5D" mean "Pseudo 3D" like raycasiting, Doom style rendering which is different then ray-casting, 3D voxels using 2D sliced images to make up a 3D object or 3D box values in 2D space, 2D metaballs or even 3D metaballs that use simple shapes to produce countless polys on the fly and so-on... My hope is to one day find a way beyond the traditional confines of a large 3D data set and take away the restrictions of polygon counts. Inspired by the old VistaPro program, the file sizes prior to being rendered are a fraction of what the program actually produces on account that the program has to calculate all of the 3D math to produce it. Well the Jaguar's strength is in the 2.5D/Pseudo 3D stuff so a hybrid of both 2.5D (third mention) and real 3D seems to be the thing to pursue with the Motorola and/or DSP doing some real 3D work while the GPU with OP and BP rendering something in Pseudo 3D or fake 3D based on a real 3D framework and maybe some other pre-rendered or pre-calculated stuff to fake a high polygon object that may have been modeled in Blender or Zbrush without it being a large data set.

 

https://en.wikipedia.org/wiki/2.5D

 

I did some similar-looking experiments. This particular one is not using Blitter for lines - just drawing them pixel-by-pixel from GPU:

 

 

So, you can expect a similar output from DSP (again, from GPU, I was doing 8-bit access, so the DSP's 16-bit is more than adequate). Of course, minus the bus lock, as when the GPU is accessing framebuffer, the DSP has to wait, and vice versa.

 

Using GPU to draw lines pixel-by-pixel gives you a tremendous advantage in the visuals, as Blitter cannot do the shading at 256 color mode.

But, on GPU, you can do it very easy (note the colorful lines):

 

Man I got to commend you on the 3D work you managed to get out of the Jaguar so far... Keep up the good work.

 

Honestly, the best bet would be to use the GPU to do it's job as intended, performing the vector maths calcs and feeding work to the blitter. Use the blitter to build the output in a frame buffer, and then once drawn, point the OP at it. You don't have any risks of a single scan line being too complex and taking too long messing the whole thing up that way, you only show a frame when it's ready, and you get no tearing when there is movement.

 

Us the OP and blitter as they were intended too, the system will work with you then, not against you. Use the 68K sparingly if you don't have the bus time, or as a manager for your game, leave the DSP for all the other bits and bobs, or even use it as the main system loop and bin off the 68K.

 

But don't try rendering your 3D scene into the scan-line buffer 2600 style with the GPU, there be dragons, headaches, and an ultimately sub par result. The jag can do 3D, same as significantly less powerful systems could do in the late 80's.. Jag can do it better I am sure and faster, until you start trying to treat it like a modern system (which don't forget is 20+ years it's junior, and computer tech increases in performance exponentially).

 

Duly noted buddy... I was looking at the old "Chase The Beam" theory for the Jag... It's more like "Chase The Line" in the Jaguar case. Even by 1995, just a couple of years after the Jaguar release, the average PC that did 3D graphics ran at 60 or more megahertz, which wasn't available to the masses in 93 and 94 unless one owned a graphics workstation like the SGI stuff. Even the 3DO arms chip was proven in the Acorn PCs to do decent 3D stuff. Don't mean to give a history in that sort of thing and throw the topic off, but the best you had with 3D past 60fps was Doom, Super Burnout, Val d'Isere Skiiing, and Atari Karts showing some promise and let's not forget the voxel stuff. I want to get the GPU to produce better 3D graphics in the same kind of way it was able to produce those fast frame rates in these 2.5D games only smarter.

Edited March 27, 2018 by philipj

[VladR]

Typing on tablet, so cannot properly quote:

 

1. 68k off the bus

- all my 60 fps demos have 68000 running in background, banging on the bus

- only recently, with Stunrunner, I started offloading stages of 3d pipeline from GPU to 68000 and it's 68000 that allowed me to increase scene complexity and raise framerate.

 

The core takeaway is that performance delta with 68000 off is lower than when it's on.It's a 13.3 MHz CPU that can do a lot at 60 fps. Sure, it is much much less than GPU and I don't argue that. But just think what Atari ST can do with 68000 at 60 fps - plus factor in frequency difference to jag - and that's the performance you are leaving on the table by shutting 68000 off - all for perhaps 5-7% more GPU performance.

 

I can tell you for sure that I would drop 50% in frame rate if I stopped using 68000, as I would have to start swapping code, which is very expensive and with vsync it is 60 or 30 fps, nothing in between

 

 

2. 2.5D

- I see now that you mean by that a large group of techniques

- some are better suited to jag HW than others

- don't forget that impostoring is still being used even on ps4, so why not on jag?

[philipj]

I was never an Atari ST owner, just a 2600 buff in the 80s, I wish I had an ST back in the day though. Recently I ran into a book at www.archive.org when looking for some Motorola 68000 assembly programming books. The book is called "Real-Time 3D Graphics for The Atari ST" and one other 3D graphic book for the ST that's sparked my interest a little more toward the 68K so I'm certainly looking at some possibilities with the CPU... I'll leave a couple of pdf files.

 

https://archive.org/details/Real-Time_3D_Graphics_for_the_Atari_ST_1991

 

 

 

Real-Time_3D_Graphics_for_the_Atari_ST_1991.pdf

Atari_ST_3D_Graphics_Programming_Concepts_And_TechniquesuBee.pdf

Edited March 28, 2018 by philipj

[philipj]

Ok... Here's another impressive game call "Racin' Force" that uses voxels as well as the 68000 processor; I see the arcade board uses a series of graphic chips, but I don't see if they were math chips... Whatever the case, this looks feasible to do on the Jaguar hardware considering it's ability to do voxel really well. Any kind of fast pseudo 3D for the Jag will probably be volumetric in nature in order to get those blazing fast non polygonal pseudo 3D graphics. Voxels doesn't look very good unless it's in high resolution, but it's possible to cheat jagged edges from voxels by clipping the edges at it's drawing points via the object processor. Just some tid-bit thought on some ideas; sometimes I look at 3D stuff and my brianstorming goes into overdrive.

 

 

http://www.system16.com/hardware.php?id=574&gid=854#854

Edited April 28, 2018 by philipj

[Sinigord]

The object processor is a very cool piece of hardware for its time, designed by some very smart people with no common sense. Had they not tried to squish all the data together in the object list and just used an extra 4 bytes to allow things to be on 8 or 16 bit offsets, all the software building the object list would be so much more efficient, no need to shift stuff left and right and cut bits off to make it fit.

[Zerosquare]

Remember that the object processor runs on every video line. Adding an extra half-phrase per object would have a significant impact on the bandwidth usage, not to mention alignment problems.

 

The object list building code, on the other hand, only runs once per frame at most (and only for moving objects if you're a bit clever).

 

Maybe they Jaguar designers had more common sense that you think

[philipj]

Remember that the object processor runs on every video line. Adding an extra half-phrase per object would have a significant impact on the bandwidth usage, not to mention alignment problems.

 

The object list building code, on the other hand, only runs once per frame at most (and only for moving objects if you're a bit clever).

 

Maybe they Jaguar designers had more common sense that you think

Sort of reminds me of the Atari 7800 graphics chip that uses a display list where the graphics isn't pixel based per-say, but based on list being sent to the graphics chip only in the case of the Jaguar, the OP is programmable... Very fast graphics and untapped potential never fully taken advantage of.

[phoenixdownita]

Sort of reminds me of the Atari 7800 graphics chip that uses a display list where the graphics isn't pixel based per-say, but based on list being sent to the graphics chip only in the case of the Jaguar, the OP is programmable... Very fast graphics and untapped potential never fully taken advantage of.

I'm pretty sure the programmers of Super Burnout took a good crack at tapping that untapped whatev ...

[+CyranoJ]

the OP is programmable...

 

That is a bit of a stretch....

[philipj]

I'm pretty sure the programmers of Super Burnout took a good crack at tapping that untapped whatev ...

 

Well that goes without saying obviously; its ability to scale pixels really fast... My thing real-time manipulation of the OP list via the RISC before it actually reaches the OP, but that's for another day. Here's an insert from the Jaguar Manual...

 

 

Object Processor

The Object Processor is responsible for generating the display. For each display line it processes a set

of commands - the object list - and generates the display for that line in an internal line buffer.

Objects may be bit maps in a range of display resolutions, they may be scaled, conditional actions may

be performed within the object list, and interrupts to the Graphics Processor may be generated.

 

I want to exploit the living day-lights out of those "Conditional Actions" on a whole-other level if possible... At least that's my intentions.

 

 

That is a bit of a stretch....

 

Well... I know it can't be programmed like the RISC or the 68000 can, but you can certainly do more stuff in comparison to the 7800 graphics chip that's totally dependent on 6502 that slows the system down by default... That's the point I was conveying.

 

Edited April 30, 2018 by philipj

[phoenixdownita]

...

I want to exploit the living day-lights out of those "Conditional Actions" on a whole-other level if possible... At least that's my intentions.

...

Forgive me for being jaded about this whole subject .... I don't mean to discourage you but I doubt you'll find any holy grail of untapped power, but please as long as you enjoy the hobby keep on doing what makes you happy.

[+CyranoJ]

The conditional actions allow you to shorten the lists to allow more objects on screen at once. To use them requires additional coding to process the object list (clipping sprites to the branch points, possibly inserting them into multiple branches, etc). The time spent doing this probably negates the time saved.

 

The GPU object is bugged to hell and fires on all lines so actually requires 2 branches before it to be of any use, otherwise the GPU has to count lines and work out which one it is on.

 

All in all, meh.

 

The Facts demo shows what can be done here, however the object lists blow an obscene amount of memory

[phoenixdownita]

....

 

The Facts demo shows what can be done here, however the object lists blow an obscene amount of memory

Link or it never happened:

https://youtu.be/3e_3q9U5tFo

 

Wonder if it's 30fps or 60fps .... we'll know soon enough

[+Stephen]

[ full sarcasm mode on ]

We need to see something that shows the boxed promise of 850,000 pixels per second rendering. I know we don't have Blast Processing™ as that was reserved for SEGA Also, I think the box forgot to mention that to get that speed, you needed monochrome (1 bpp). So if we wanted a paltry 256 colours, we drop to 106,250 pixels per second. Let's assume an old school Commodore 64 sprite of 24*21, and we get 210 sprites per second. I guess that's not too shabby.

 

Using the Atari 8-bit's more advanced 8*256 strips (oh, I mean sprites) which I will grant were in monochrome (but DLIs could get you a different colour per scanline so I say we count them as 8-bit) we only get 51.8 per second.

 

Is all this meaningless drivel - I am sure it is. But really - is the Jag the uber sprite crunching beast it was portrayed to be? Or was it more like the 7800 (display too much and your CPU stalls because of single bus)?

[ / back to reality ]

[Zerosquare]

Wonder if it's 30fps or 60fps .... we'll know soon enough

The answer is in the intro screen:

- about 1,900 objects displayed per frame

- about 110,000 objects displayed per second

-> 60 fps

[phoenixdownita]

The answer is in the intro screen:

- about 1,900 objects displayed per frame

- about 110,000 objects displayed per second

-> 60 fps

<sarcasm>

C'mon now, it's not 60 or 30 or 15 until "the Master FrameCounter" said so.

Psst, amateurs ... believing we will trust what the programmer said or the hints left in the intro screen, it's like believing the doctor when he tells you you need an appendectomy or shows you your ultrasonography ... he knows nothing, the plumber said to gurgle down some "Tibetan herbs" and to call it a day ... so herbs it is.

</sarcasm>

[philipj]

Ok... Here's another little nugget that can serve as a great example for using the Object Processor... If my memory serves me well, the "Wolfenstien" demo for the Atari 8bit wasn't a raycasting program, but was a scan-line based program that used "interrupts" to pull of the pseudo 3D effects. Someone can correct me if I'm wrong with the info or give a link to the topic that covers this project as I would like to know more about it. I guess Doom for the Jag kind of demonstrates very efficient scan-line based rendering in real-time. I'd like to see more creative stuff in this regard.

 

Edited May 7, 2018 by philipj

[+CyranoJ]

Doom for the Jaguar renders in vertical strips so splitting the scene up this way (doom) using the Object process would make no sense at all as branch objects could not be used.

[Zerosquare]

Well you could use lines instead of columns, and tell the player to turn their TV screen (or head) 90 degrees...

[VladR]

<sarcasm>

C'mon now, it's not 60 or 30 or 15 until "the Master FrameCounter" said so.

Psst, amateurs ... believing we will trust what the programmer said or the hints left in the intro screen, it's like believing the doctor when he tells you you need an appendectomy or shows you your ultrasonography ... he knows nothing, the plumber said to gurgle down some "Tibetan herbs" and to call it a day ... so herbs it is.

</sarcasm>

Awwwww, you're so sweet ! I love you too, darling I wouldn't however waste my breath on such a synthetic benchmark

 

That benchmark does, however, show that a bullet-hell-style game is totally doable on Jaguar. With one caveat - it requires a tiny little bit of a new-code effort, though !

 

 

 

 

Hmmmm, I wonder, why hasn't nobody, who might already be putzing around these 2D games on jag, attempted one ?

 

Oh, I know ! Nobody wrote one for Atari ST ! There's no pre-existing codebase to parasite on! Oh, shoot!

 

 

 

 

Because if there actually was such an Atari ST game,

[VladR]

Ok... Here's another little nugget that can serve as a great example for using the Object Processor... If my memory serves me well, the "Wolfenstien" demo for the Atari 8bit wasn't a raycasting program, but was a scan-line based program that used "interrupts" to pull of the pseudo 3D effects. Someone can correct me if I'm wrong with the info or give a link to the topic that covers this project as I would like to know more about it. I guess Doom for the Jag kind of demonstrates very efficient scan-line based rendering in real-time. I'd like to see more creative stuff in this regard.

 

While I haven't looked into how exactly does Project-M do the rendering, but from my experience with my 6502 flatshader, the scanline filling approach on Atari 800 is very fast because of the following:

- unrolled STA takes just 4 cycles

- at Antic $0D mode, that's 4 pixels, e.g 1 cycle / pixel

- you have 24,954 cycles available per frame (at 60 fps) (after Antic is finished with its highway robbery), so it's quite a number of pixels you can fill and retain 60 fps

- of course, interlacing halves the number of scanlines, and pixels, and increases the available cycle budget for 6502 CPU

- since you can program Antic (a precursor to the OP in jaguar), you can align each scanline at a page boundary, thus allowing you to jump across scanlines via a simple INC vidptrHi, that takes just 5 cycles

 

- of course, even a non-unrolled code is still fast - an indexed STA addr, X takes just 5 cycles (and INX takes 2c), so you can fill the scanline very fast

 

 

6502 is, indeed, for its time, a very fine technological achievement, as a lot of ops take just 2cycles (not easy to accomplish even on jag's RISCs with its pipelined architecture)