Jump to content

philipj

Members
  • Content Count

    932
  • Joined

  • Last visited

Everything posted by philipj

  1. That's why I said not without the help of the RISC... The OP alone scales sprites, but a mode 7 like affect can rotate a background sprite or make it appear like it's rotating on multiple layers using multiple sprites. "Super Contra" for the SNES did this demonstrated that effect on the second level using SNES mode 7; something similar can be done on the Jaguar, that much is clear. In the case of "Red Zone" for the Genesis, it appears that sprite rotation is 2D polygon based so the goal for the Atari Jaguar would be to find a balance between the two to yield a better result... But yea I see how that sort of statement can throw someone off and sometimes I do forget certain details from the Jaguar manual, however my point was/is to show it is possible if not unconventionally, but with the Jaguar unconventional seems to be the rule if you want to get something really special out of it as far as visual are concerned. For ever flaw the Jag has, there are some benefits so there's always a way to do something if you really want it done; but I've always been an optimistic dude. I haven't fully felt the pain of programming the Jaguar yet. lol Agreed... Just something I'd like to personally see done for myself and I know others who would like to see more 3D content for the Jag. It's a project I started on some years back that I like to see finished.
  2. Right... On that note, the hardware limitations are even fewer than the Playstation 1, but certainly much higher than the SNES or the Genesis. Although the SNES mode 7 effects are limited to background images, the Jag doesn't have that limitation. Certainly the Genesis 68000 can pull off the same kind of effect using software using a non-programmable video chip with 64kb of video ram, yet the Jag has more main memory to work with less video ram, but faster programmable gpu that can certainly do a lot more than what the geny can do. Trying to get a modern 3D engine or even a 3D engine from the early or mid 90s won't be without some level it taxing the system on some level. The Jaguar is very different and unique animal all together and requires a very different approach from the normal; at least in theory that's the case. I don't really know how smart it is, but I hope to experiment with a 3D engine using the Motorola 68000 to render fast wire-frame based rendering while the GPU to do fast polygon fill, shading, and small size texture mapping. Take a look at "Red Zone" for the Sega Genesis below... Look at how fast the Genesis is able to rotate low color depth textures in the helicopter scene probably no more than 16 colors... Now does that not describe what the Object Processor does; scale and rotate small sprites with some help from the RISC? I'm think small sprite size textures even if it's a series of small sprites to make up a large image would probably be the way to go to get the most out of the Jags texture mapping situation. If it's dithered, you can use copies of the same sprite over and over again; hat would be a good starting point. And then there's the "Star Fox" demo for the Genesis using just the 68K to do all of the 3D calculations using 72KB of system ram... If it wasn't for the color fills, the 3D could probably move faster just rendering wire-frames with hidden surfaces so there are ways to do things, just can't quite do it the way it was done on a PlayStation 1 or Sega Saturn unless is shrunk to manageable pace the Jaguar can handle and it can probably handle it. Also if you think about Virtua Racing using the SVP chip on a cartridge for the Genesis, it used a 16bit samsung DSP to pull off those low polygon graphics. https://youtu.be/zzBc5a3frlY?t=1m59s
  3. Why not make a proof of concept 3D engine on PC first based on what you already know about the Jaguar... That way you can make your own format ready to go when you implement/migrate 3D engine concept to the Atari Jaguar. Not to knock what you've already have done, just a prototype done on PC based on the work you've already have done on the Jaguar and establish a framework between the PC and Jaguar for 3D engine? I haven't done any serious 3D modeling in 3D max in a long time... I've almost forgotten how to use Max. Here's something I did back in 05 taking up a 3D surfacing class for CAD back in 05. The model was done using "Nurbs or Spline" modelling; later I would learn box modelling, but that's another story. The image was based off of a 2D drawing. I got to get back into 3D modeling... I miss it. Making Jag games would certainly help get me back to getting my stride in 3D stuff.
  4. True enough... That's always been the issue with the Jaguar back then and even more so today. Maybe one day that'll change. Lol...! Time flies.
  5. Man I sure was clueless back in those days... I'd barely read all the way through the Jaguar manual back in 05, but was familiar with the unofficial "Jaguar Dox"... This topic hasn't been touched since 2005 until today... Time sure flies. For the record, here's my super late response... Back then I had "Protector SE" game cartridge which had a copy of good old "BJL" limited when you press a certain button number on the control pad for a few seconds. I had trouble getting it going using the then newer version of Windows XP 64 and didn't really understand the mechanics of how it all worked. You needed a "printer2jag" connector for connecting a PC to a Jaguar via the printer port. Otherwise the old BJL (Behind Jaguar Lines) required replacing the Jaguar bios chip with one that contained the BJL firmware in order to bypass the cartridge encryption, which plagued the Jaguar community to no end before the official Atari encryption key was found making it possible for flash cartridge like the Skunkboard and the up coming SD cartridge possible. This is an old topic and very late in response which seem to have been the ending point to this relevant topic, but it's a bit fun to run down the history to all of that stuff as I currently understand it. Why let the knowledge go to waste??? I guess the idea of reverse engineering the Atari Jaguar chip sets was a bit of a none issue even back then, but than again... Has anyone ever considered reverse engineering the Jaguar? I'm not talking about unscrewing the motherboard from the case and having a look-see at the circuit board; well yes that too... I'm talking about cracking open the processors and chips itself to see what their made of... Chances are if you're still tinkering around programming the Jaguar after all of these years, you may as well go all the way with it %100 or just plain move on in life. lol Below is a video of the infamous Capcom "CPS1" arcade board that's being pretty much dissected revealing the graphic inner workings and so-on. I'd like to see something like this for the Jag system. I know topic is a bit of a throw back, but I think it's still a relevant topic... Wouldn't it be cool to have a public scrutiny of the Jaguar's inner workings like you see in the video below reverse engineering?
  6. I got a copy... I use to play around with the 3DStudio Max files animation sequences. I even had a JS2 copy of the Beta version limited release before I sold it sometime back. I hope this helps out. FFLSource.zip
  7. Man I remember years ago I wanted to do the "Sega SVP" thing on the Atari 7800; basically a cartridge with a dsp on it for the 7800 to do some 3D stuff on that system... I still do in a way. At one time I thought the 7800 could handled limited 3D before I got a little better educated on some stuff; I mean it is possible, just not in the way that I thought and it's probably similar with the 3D stuff I'd like to do with the Jaguar although I'm always looking for ways to get around things if possible, but that's just something/a dream rather that I'm personally chasing and whatever I post sometimes have a lot to do with my own personal opinions and doesn't always reflect others; I'm still in the learning stages. The beauty about this "I-Robot" arcade system was that it featured the 8bit Motorola 6809 with four 4bit amd 2901 bit slicers on it to do 3D math (Mathbox). Looking up info on the 2901 I've learned a lot about how widely used the chip was in Universities and industry on system that required that extra horsepower before the use of PCs become a household thing. The good thing about today concerning the Jaguar is the available information out there now that wasn't always as easy to get previously when only a few people really knew how to get most out of the Jaguar, but I think it'll all boil down to the understanding of fundamentals more than anything and for me that would be learning Assembly "where the rubber meets the road", but to each their own; whatever is easier I say go for it. At this point any good game release is better than no game release, but i hope to push the system as far as I can push it and because of that, I have a lot of crazy ideas that probably wouldn't catch on as well as I would like it to as been the case in the past. lol
  8. It's a bit related and not related at the same time I just ran into this old commercial concerning the "S.T.U.N.Runner" arcade hardware. At the moment I'm just posting for kicks; I thought about this post when I saw this. The arcade used 2 TMS DSP processors for "Hard Drivin" simulator/arcade... The commercial highlights the "TMS 34010", which I thought was very interesting worth posting. http://www.system16.com/hardware.php?id=770
  9. Thanks a bunch for the link... The attention to details on the racing vehicle 3D model is very interesting to say the least considering the PS1 or the Saturn couldn't handle such high detail models, but it's very evident in the "design document".
  10. I hear you man... There's a trick I learned concerning how they implemented background images when I took up a 3D modelling course a few years back... You create a low polygon filled half-dome and apply a texture-map background image to it. The dome should be bigger than the actual 3D scene and usually the bigger the better to simulate open sky/world that's why the background in Wipeout seems to move with the scene instead of the flat background image you'll see in Checkered Flag for the Jag. At least that was the old school way of doing it; I think today they have some kind of HDR thing with background image in modern games???
  11. I know right...? Another thing I noticed about "Scorcher" for the Sega Saturn is that the racing track is highly modular just like "Checkered Flag" for the Jaguar, but doesn't use high detailed polygon backgrounds the way CF did. A game like "Wipeout 2097" for the Playstation 1 seems to work within draw distances limitations much like "Ridge Racer" both the track and the background are reasonably rendered fully in real-time without it looking like the edge of the world are a few feet away because all of the polys aren't rendering fast enough... Got to get around the polygon limitations somehow or at least work within it. Here's a video of "Wipeout" for the PS1 the tracks meets the limits of draw distances; the scenes fully rendered enough to not dissipate within distance. Well... There's a little polygon dissipation, but just barely. Note: The video is in HD so it's clearly emulated.
  12. I found a TI-99/4a at a local thrift store still in the box for $32 a few month back, it was in good shape, I hated to walk away from it so now I'm a TI owner... Been doing online research on it ever since... This will be very helpful; thanks Tursi.
  13. Scorcher was made by the people who did the famous 32X demo for the Sega genesis add-on module... You should check out some the work they've done on the Sega Genesis; next to "Codemasters" these were real good in tweaking the living crap out of a computer with a Motorola 68000 thus they came from the Amiga demo-scene. I'm not going to post any of their Sega Genesis stuff, but the 32X demo seems very appropriate this topic. I wish there was more info on how they were able to pull off their tricks... The Sega Saturn doesn't really have the kind of hardware that the PS1 have where the inner components tested and tried in the computer graphic workstation market versus the Saturn based off of Arcade hardware where Sega clearly did their homework before the release of "Virtue Racer". Sega is another company that is king of the scaling and rotating sprites starting with "Buck Rogers Planet Of Zoom" and making a slew of other pseudo 3D games afterwards like Out Runner, Hang On, Space Harrier just to name a few taking good advantage of the 68000, but I can go on and on with that stuff so I'll end here. lol ZYRINX 32X Demo Video
  14. StunRunner has a bit of some physics when you hit those tunnels... If you hit the corners the wrong way, you'll slow the vehicle down. The arcade version probably got the 68000 doing all of he physics similar "Checkard Flag". You probably can animate the vehicles enough to respond in a realistic way that way the game is operating off simple animation instead of some complex physics engine; of course that idea may vary depending on what you're trying to do. Here's something for reference; a book called "Mathematics for Game Developers". Seem to cover a lot of stuff including game physics... Don't know how practical it is for the Jaguar, but it seem to cover some good angles. https://ia800201.us.archive.org/13/items/Mathematics_For_Game_Developers_2004/Mathematics_For_Game_Developers_2004.pdf
  15. Here's an Atari ST port that I've taken interest in lately... The source codes in this book to the Jaguar for experimental purposes. "The book "Real Time 3D Graphics for The Atari ST" was written for a system with 512kb of ram; I'm curious to what the book has to offer. https://archive.org/details/Real-Time_3D_Graphics_for_the_Atari_ST_1991
  16. I remember around 87 or 88 I nearly owned an "Atari XE" game console, however at that time, an older cousin of mine had given me all of his Atari 2600 collection. When I went to the "Toy R Us" store to get a 2600 system for the game I saw the XE on display over there, but when I looked at the cartridge slot I saw how small it was. I reasoned that I couldn't play the 2600 games on that thing so I wind up getting the newly released 2600 Jr so you're right about what you're saying.
  17. Here's a video of a LISP based 3D editor that was used to develop the Nintendo 64 system...
  18. Naughty-dog used LISP for character animation and such... The rest of the game was done in C and Assembly. What turned me on to LISP was actually seeing a version of it work in "AutoCAD" during a CAD class session a few years ago (I took up Computer Aided Drafting back in the day). I only seen it once in a demonstration where we typed a few codes in AutoLISP, really a "follow by example" kind of thing with that, where a 3D clock was created in code with 3D extruded numbers placed in the clock via LISP with clock hands spinning in a looped animation; all 3D objects coded in AutoLISP. With more coding, it could've been synced to a real time clock scheme, which was what made the demo so memorable. Although "Crash Bandicoot" used LISP for character animation, LISP can be used to do full on 3D and have been used in the past on lesser machines excluded the 68000 processor itself... I don't know how practical real-time 3D is in LISP particularly on the Jag, but it's still a fascinating idea IMO. I always wanted to try my hand with LISP again, but its just an idea at this point.
  19. Technically it's possible to port LISP to the Jaguar thanks to "FRANZ LISP" prototype open source code for the "Motorola 68000" processor...It was originally for a prototype SUN-1 Workstation written in C and was abandoned in favor of an ANSI version called "Common LISP". I don't know how far one would get using LISP on the Jag, but the idea is pretty intriguing to me considering "Crash Bandicoot" for the Playstation 1 was written in LISP; they customized the language just to make games on the PS1 using Alegro Common LISP.
  20. 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.
  21. 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.
  22. 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... :
  23. OK... Here's a video I ran into recently concerning a sprites on the Neo Geo. Here's the YouTube description;
  24. 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.
×
×
  • Create New...