philipj

I originally posted this YouTube in another topic, but this video is so worth posting here. It really gives a good visual of how sprite works on the Neo Geo, but can be applied to the Atari Jaguar, which could possibly yield a better frame rate. It think it quite clever how SNK applied animated sprites in the way that they did.

It's just an idea I'm putting out there; that's all... Besides any kind of problems that one might have with buffering, there's always a way to find leverage over performance vs speed. It's not like the 8bit that uses a display list on a system that has limited memory in bytes and kilobytes. If there's a way to get more than 15 to 20fps using main ram access then I'll use it with no bones about it, I guess that opinion would go for anyone here. It's possible for OP lines to be stacked in rows in main memory to be streamed back via the blitter really fast and it probably wouldn't take a whole lot of memory to do so if it's 8 to 10 lines. That's like 16 to 18kb? That's also something I've given some thought to and that's the Jaguar bottleneck bus... The processors doesn't always have to run parallel to each other; a pipeline that helps to free the bus is something that I'm looking into as a way of making the most out of the bottlenecks. I don't recall referring to the 5200 or the 7800 as machines that chases the beam... Those systems uses a list to display graphics; they both do so differently from each other, but the concept of a list streaming to a graphics chip is similar. Besides the 7800 graphic chip is much faster than the processor that runs it every time it hits the bus just like the 68000 when it hogs the bus on the Atari Jaguar whenever it's in use; but I certainly understand wanting to take advantage of the GPU speeds in internal cache. Well the Neo Geo was an interesting find and seem worth posting... I probably should've put in the OP topic, but I posted regardless and thought it a very cool video to post. It really put sprite based graphics in to a great visual perspective; I'll have to post this video in the OP topic. It's one more reason I believe Neo Geo games can probably be ported to the Jaguar even if the GPU to main memory it would be slow, but it would be fast enough emulate the Neo Geo well enough to pull off 30 or more frames per second. Well a few stack of OP lines about 8 or 10 lines probably wouldn't take up a whole lot of memory, sounds like a good place to start... I know I mentioned 500kb earlier because that seems like a reasonable number to work with, but really less then half that number seems even more reasonable. Point is I'm willing to compromise on putting main ram to good use if it means getting a steady stream of lines streaming back to the OP via the blitter. By saving lines in main memory, that's 4 to 5 times the line that GPU cache currently handles so yea there's a bit of the "chasing the beam" affect going on, but it's done in a way the Jaguar quite possibly handle steadily using OP lines if it's done right. The GPU can pre-render a 3D image and have the blitter stream it back to the OP; it's like streaming a 2D image if the lines are in place for streaming. I saw the numbers you posted at almost 10 times the wait? Well it's close to 8 times the wait time, which possibly makes the GPU run as fast as the Motorola 68K using RISC instructions, which is double the speed of CISC. The access to main would only be for a very short time using only almost less then 30 kilobytes if i was to use between 8 to 10 lines; the only issue would be texture mapping, sound, anything that would take a lot of memory, which I'm looking into a procedural method of graphics... Maybe some kind of sprite pattern thing using dithering or something; make good use of the Blitter ability to copy really fast. To be honest I haven't had any time to do a lot of the stuff I'd like to do... Don't know if I need to put this out there, but I spent the last 8 or 9 weeks recouping from a knee surgery I had after I fell and ripped a muscle. Things are getting better now, but man what a slow down weeks prior; still recouping, but I'm definitely a whole lot better off today... Surgery is no joke. lol That's life though, once I'm fully up and going, I have a family waiting to take up even more of my time. What can you do? Gotta make time for my hobbies.

I wouldn't call it chasing the beam... It's more like chasing the OP line than chasing the beam; to some degree it really isn't that either. It's more or less preserving the lines in main for later usage. If a line is pre-rendered in main ram, the hope is to leverage enough lines in main for the sake of producing a consistent "Persistence Of Motion"; or at least enough lines to have some leverage over frame rates. Now that much I wouldn't doubt in the least... This is the Jaguar we're talking about, not a magical kitty riding a unicorn (pun intended). However I think it could be possible to preserve enough OP lines in main to get some kind of controlled frame rate at a respectable pace while leveraging any lagging in the process. The kind real time 2600 chasing the beam theory is something that I once thought was possible on the Jag, but the Jag is just made different thus the theory can't really apply using conventional means. However I do feel like it's possible to have a more reserved approach by saving enough OP lines in main to get a decent frame rate then have the Blitter to copy a few of the lines back for fast OP draw. @LinkoVitch I got my definition of a framebuffer from "Wikipedia"... I claims that color values are stored in memory to be drawn to screen versus the old chasing the beam theory where a line is drawn using a single beam of light on the 2600. I know you didn't bring up the chasing the beam thing, just making a distinction-that's all. A single OP line is enough to fit on the GPU internal memory so it wouldn't too much memory if small sections of a screen is drawn in a series of OP lines in main. The Blitter can copy those lines for fast OP draws with more lines still reserved in main; it would make for a great frame rate leveraging tool. @sh3-rg All magical kitties riding a unicorn aside... :

????

OK... Here's a video I ran into recently concerning a sprites on the Neo Geo. Here's the YouTube description;

Well... I'm aware of that. GPU to main requires full 64bit access due to an 8bit multiplexer not getting enough current when trying to make jumps, so small function like AI and such is suitable for access to main ram. Anything more than that and you're basically "Hammering the GPU" or taxing the GPU from performance. It seems feasible for a scan-line based render-er to benefit if a few lines are pre-rendered in main ram before it hits the OP. It wouldn't have to be a full screen, but maybe a very small portion of a screen size where one or two (or more) lines of graphics can be fetched from main before it hits the screen. Or 64x64 sprite based graphics could be fetched from main memory.

OK... Another highly related video has surfaced under my radar concerning the "Bell Labs Alles Machine"; the conceptual heart of the "AMY Processor"... Mostly just a lot of noise making, but it's good to see a machine still in existence today... This video was made last year 2017.

I think double, triple, or more frame buffering situation could yield faster frame rates if done in main-ram; could certainly help with any slowdown or choppiness if pre-rendered frames are in a constant stream instead of rendering individual frames on the fly... It seems necessary in the Jaguar case. Dedicate about 500kb or more main-ram just for GPU stuff seems ideal. OWL's demo is definitely a fine example of what's possible using the "GPU to Main RAM" should be exploited even more despite whatever the short comings are.

I heard that the bus that the DSP sits on is full 32bit instead of 16bit like the game console...

The 68020 would be better... The internal cache would've been a wonderful addition especially keeping the 68K off of the bus even for but a short time. At least if someone does an fpga copy of the Jaguar hardware they could possibly use a 68020 or higher model chip.

Ok... Here's a non related synth chip called the "DSP-G1" by a company called "DSP Synthesizers"... Just a small little perspective on the current state of affairs concerning modern day synth chips. I know the "Speakjet" had some potential, but didn't really specialize in music or didn't have anyone to exploit it's musical potential. It's good to see synth chips are still being made today; it would be cool to see them do something with the AMY specs.

They're always out of stock when I visit this sight... Is there anywhere else they sell these boards??? I'd like to get my hands on one.

Right... And the "GPU-to-main work around" requires full 64bit due to a bug with the multiplexer not getting enough current when making jumps, which means more cycles lost, but is still somewhat useful provided the access isn't in a tight loop less you wind up "Hammering the GPU". Makes for great limited use like AI and the such, but still very limited when it comes to graphics for texture mapping in a speedy manner. The GPU has a great ALU on it that's fast; it seems like procedural textures would be ideal considering the two 16bit multipliers running parallel, but I guess that ram issue is always going to slow things down at some point. Here's something from the Jag manual concerning it's math capabilities... The GPU is also intended to perform rapid floating-point arithmetic. It has no floating-point instructions as such, but has some specific simple instructions that allow a limited precision floating-point library to be capable of in excess of 1 MegaFlop. One of the reasons I chose 2.5D for the GPU is because of the fast math; it would be overkill for that sort of thing... I still stay hopeful, but it's not all that surprising considering every good Jag programmer all express their frustration with the system and its bugs. At 32bits that would be 8bits x 4, but would mean 4 times the data in cache... Another reason I would refer to the DSP, 68K or both to do some 3D work prior it the GPU handling whatever the outputs are. By the time it reaches the GPU, a great majority of the work is already done. Simply let the GPU do some fast 2D rendering based on the per-calculated stuff since the DSP have full access to main ram at 16bits. But the info you're dishing is very helpful only confirming a lot of stuff that I here from Jag programmers. I read somewhere that the Jaguar can do 720x480... Every tried another resolution size? Your vertical res is low, but you use a lot of lines within that low res. If the Jag can handle that many lines, seems like something a little more modest in resolution might be in order, which could help to free up some cycles.

There's one more thing I forgot to mention about "Project M" on the Atari XE130... The texture used in the "Wolfenstien" demo; they didn't use any bit maps, but was done in assembly/binary code, which I thought was pretty interesting. It's a very note worthy mention; I wonder if the Jag could do something procedural with texture mapping for the sake of speed and memory? That would certainly help tilt the unbalanced nature of the buggy Jaguar if the textures were very small, compact, yet machine code fast for that on-the-fly real-time rendering.

And to think I had a 1200XL and sold it... What was I thinking. It was the "Mr Wizard" Atari system of all systems. lol Well the info I got from the "M Project" came straight from the horses mouth/the guy who posted the YouTube in a comment some years back when he first posted it. At first I thought he was using some raycasting on the Atari 8 computer, which was done once before, but not quite the way this guy seemed to have pulled it off at that kind of resolution. I can't seem to find the actual quote, but no ray casting was used, it was full on scan-lines using interrupts to do all of the pseudo 3D effects; that much I do remember considering at that time I was looking at the Atari 7800 graphic chip able to use display-list, which is very different then the 130xl graphic chip, yet share some common ground with the Jaguar's OP able to display almost in similar manner. It seem like whatever the Jaguar OP lacks in comparison to the Atari 8s graphic ability, could be made up in speed, but then again, even the Atari 8bit computer had a little more ram to do more graphical things then the Jags GPU with only 4KB of internal. My thing is this, the GPU is a 2D monster very capable of doing 2D display and manipulation in real-time without breaking a sweat, which I've always credited as the Jaguar's strength... If 3D can be done using the DSP or the M68K or both very minimally using low poly based 3D models, and I mean low poly to the bone for the sake of speed and broad view distance, the GPU can interpret 3D data and render fairly accurate pseudo 3D/2.5D based of real 3D math as a way to fake high polygon objects in a similar fashion a voxel height-map is used or 2D meta-balls are used to render high detailed 3D images to screen only in this case, pseudo 3D is faked to look like real 3D high poly objects when in reality no real polygon is used, it just looks that way. It doesn't have to be voxel or metaballs per-say; just a smarter way to convey high detailed 3D in a way that takes the polygon count out of the equation or "Limitless 3D" as I use to say back in the old JS2 days; only its a new day today, I have a better understanding on things today then I did back in the day. That's what I mean by faking the living daylights out of 3D if that make any since to anyone.

Hold up now... First off I respect the mods over there and what they've brought to the table on Facebook. I don't know about anyone else, but they've been nothing but kind and inviting to me over there otherwise I wouldn't have vented there; I regard them as great people a particular moderator as good friend he's a straight up fellow if you ask me. Please dude... Don't insult my friends.

Hey man, I apologize for that; I didn't realize the gravity of what I did until after the comments. Besides my frustration was elsewhere beyond the forum and I just vented needlessly. I certainly don't want to cause the stir that I did, but it happened and I kind of wish it didn't after the fact. I don't want to make anymore problems for anyone here and I usually don't and haven't in times past. Now I've had people come me and start trouble with me here in the past and I simply never fed into that sort of thing thus was one of the reasons I left the scene for a minute, but I'm not here for that today. I took something the wrong way not really knowing if any of that old stuff from the JS2 days really died down since I've left the scene; it's hard to read attitudes behind sarcastic one liners. I'm sorry it came up, but I'm glad it came up to clear the air "I sincerely apologize for whatever trouble that post has caused". You don't know how far reaching your actions at a social media or forum are until after the fact. I want to be a contributing factor here and see more innovative stuff on the Jag personally, but I like original new releases in 2D and what-have-you even emulation. I like to see Neo Geo games work on the Jag to be honest, not to be sold, but just a great little project to work on.

Only if you make it a group thing... I usually don't get in to politics in a game forum like that.

Well that's quite a legacy; that nearly beats out some Neo Geo carts... It pulls off quite a few feats on the Jag for its time and the programmer is quite knowledgeable with the Jag; they cracked the cartridge encryption using a custom key before the official one went public in case people forgotten. I hardly call that a disappointment, but everyone is entitled to their opinion. #LegacyMatters

For that matter is that why the Jag CD units sell for so much... BTW I wish I'd gottten that game when Scatalogic first published it.

Hopefully no contraband will be found in these systems... lol This video below had me in tears when I first saw.

Dude that's awesome work... The graphics looks a little modular like it's following a path of some sorts rather than a modeled 3D environment... Kind of reminds me of "Checkered Flag"; despite the choppy frame rate, that game is probably one of the most open world 3D games to have a set of reusable 3D objects in a game. It seems like if the game wasn't in a loop with the race tracks, it could go on forever. You really got something on your hands there buddy; I really hope this engine comes out really solid for some really meaningful 3D gaming, which is a little lax these days as far as home-brewing. Great stuff man. Out of curiosity I'd find a use for it... I'll take it.

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.

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

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.