Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by philipj

  1. @philipj

    One of the tricks/design choices that Wipeout 2097 uses is to have a background image which blends with the track scenery as you can see around 1:33 of the video below (real hardware capture):


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



    • Like 1

  2. Absolutely loved that Zyrinx 32X tech demo, thanks for sharing that! Too bad about the draw distance but that thing had some really cool capabilities overshadowed completely by the next gen consoles coming through.


    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.

    • Like 1

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

  4. If you mean future Racer type games, the Saturn had:


    Gran Chaser

    High Octane


    Wipeout 2097


    Scorcher :



    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

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



  6. Atari also made the mistake of releasing Berzerk, Defender, Missile command, Pac-Man, Space Invaders, and Star Raiders for the Atari 5200 during its lifetime with a huge problem to the eye of consumers. All the games I mentioned were released for the Atari 2600 before the 5200 was released anywhere from a couple months to over 2 years depending on the game in question. The reason I mentioned this is people who seen the 5200 version of the games I mentioned could've thought in their heads didn't I bought this game for the Atari 2600 already.


    Atari also made the mistake of Atari 2600 releasing the same new games as the Atari 5200 even after system was launched and the 5200 didn't get a lot of exclusive game titles a lot. From a consumer standpoint, what Atari did was a mistake because they gave no reason for a consumer to buy their newer game console outside of better graphics and sound.


    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.

  7. And the reason why anyone would actually want to have a LISP on jag is ?


    I highly recommend reading the gamasutra's interview on the LISP usage in Crash Bandicoot.


    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.

    • Like 1


    This is probably trivia at this point, but Conrad was a Lisp guy and has since moved onto Clojure. I'm a Clojure developer, so imagine my surprise when I hear the reference to working with 90s Atari in this recent interview: https://defn.audio/episodes/2018/02/26/conrad.html.


    If you're interested in Lisps, his Land of Lisp book is highly reputed.


    I don't know him, but he should be easy to get in contact with.


    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.

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


  10. Well, so if you don't mean chasing the beam, how is this then different from double/X - buffering ? Those buffers also keep the "rasterized lines in main for later usage" - as you put it, no ?



    So, how exactly would this bring performance compared to double-buffering ?


    Also, you don't mention the single biggest issue with triple-buffering : the brutal input lag.


    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?



    It's quite OK, if the game runs at 15 fps and checks input every 4 frames. It's quite brutal, however, if the game manages to keep average 20 fps (due to triple buffering), but keeps the input lag at same 4 frames. It looks smooth enough yet the input lags disproportionally.




    Now, on jag, due to the way the final composite is done on OP, you can prioritize rendering main player, and keep the input at 60 fps, with environment at whatever framerate it can manage. But, it's not doable for all game genres and it complicates the engine design considerably...


    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.



    There is no point in doing that though. Storing scanlines in GPU RAM is incredibly wasteful (the OP lives on the same die and already has enough physical RAM attached to hold 2 (IIRC) scanlines). All the processors in the Jag are faster than "Chasing the beam" (which is the 2600 BTW not the 5200 or the 7800 systems). If you have your system doing any form of "waiting" you are wasting potential processing time. The only time it should wait is if there is nothing for it to do, or it needs player input.


    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.



    Not quite sure what the relevance of the NeoGeo video is. Composite layered output with sprites is quite common, you do precisely that with the OP in the Jag. Although there are no prescribed layers and it renders each bitmap on top of what has already been rendered, it does this a scanline at a time, (Hence if a list is poorly structured and too long you will get video distortions as the OP runs out of time/bandwidth to render a scanline.) Think of the bitmaps as being stickers, the OP list is an ordered list of how those stickers are to be affixed to the screen, and at what position. So whatever is 1st on the list is at the back, then the next image is overlayed, and then the next and so on. If one of those bitmaps is a frame buffer from a 3D renderer it will get placed like any other, dependant on where it is in the list.



    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.




    RE GPU running in main, these reads are only 32/16bit. All GPU instructions at 16bit in size, (with the one exception of MOVEI, which has a 32 bit data portion following the instruction), the GPU is a 32 bit device, it cannot access memory as a single 64 bit read, it probably does prefetch 32bit worth of data (but I am not 100% on this), and due to the physical limitations of DRAM vs SRAM it suffers performance whilst accessing main RAM just like any other device would. Hence only fairly infrequent (in terms of game code) calls are best suited for it.


    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.


    I did do a test of the speed difference and posted the code I used and the results on our website: https://www.u-235.co.uk/gpu-in-main-science/ You can try that yourself code is there and explained, so you can see yourself the speed differences. (I haven't had time to work on any of the other ideas mentioned in that article alas :) )


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

  11. Also, you keep forgetting that beam chasing is an incredible waste of performance due to all the syncing and waiting that has to happen each and every scanline (on top of your 3D engine performance cost). While it could be a fun technological exercise, in the end you'd end up with much smaller polycount/scanlinecount.



    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.


    In 3D, there's no such thing as constant performance. I have 8 different versions for scanline traversal in GPU, and each of them has very different performance characteristics. Any polygon can use any combination of those 8, so it's impossible to preprocess that (or if you did, you'd waste incredible amount of performance for something useless).


    The performance differences are more than an order of magnitude between the shortest scanline span (and the longest one) - thus this characteristics alone makes it impossible to actually gain any performance out of it overall.




    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.




    Few things wrong with your assumptions there..


    More frame buffers != higher frame rate. Each buffer needs to be populated, if the jag can produce 15 frames in a second, having an extra buffer will not make that any faster, it can still only produce 15 frames a second. Double buffering allows you to complete a frame whilst displaying the previous frame, this helps remove rendering artefacts from view (sheering etc), only giving the player a complete frame when it is ready. It doesn't slow down the production or speed it up, it just improves the experience of viewing the scene, and allows more than 1/60th of a second to produce a frame.


    From my understanding having spoken with Atari Owl over the years, the use of GPU in Main (oh god here we go again), is primarily used for low frequency type functions, NOT as anything to be used for speeding up rendering. It (for example), could mean you leave the 3D rendering code in the GPU RAM which needs speed, and then have routines that perform more administrative type roles in Main RAM. The GPU will run roughly 10x slower when running code from main RAM, but if it's only a relatively small amount of code that's ran once every frame or so, it makes it worthwhile overall.


    GPU in main is NOT a magic bullet, it is another tool/possibility that can be used to help in SOME circumstances.



    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.



    All magical kitties riding a unicorn aside... :?: :?: :?:





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


    What's really going on with sprites when you're playing Metal Slug 3. Basically, all the Metal Slug games on the NeoGeo use two background planes, one zone for "real sprites" which are dynamically reorganized each frame (that's where all the blinking comes from), and one last foreground plane.



    Few things wrong with your assumptions there..


    More frame buffers != higher frame rate. Each buffer needs to be populated, if the jag can produce 15 frames in a second, having an extra buffer will not make that any faster, it can still only produce 15 frames a second. Double buffering allows you to complete a frame whilst displaying the previous frame, this helps remove rendering artefacts from view (sheering etc), only giving the player a complete frame when it is ready. It doesn't slow down the production or speed it up, it just improves the experience of viewing the scene, and allows more than 1/60th of a second to produce a frame.


    From my understanding having spoken with Atari Owl over the years, the use of GPU in Main (oh god here we go again), is primarily used for low frequency type functions, NOT as anything to be used for speeding up rendering. It (for example), could mean you leave the 3D rendering code in the GPU RAM which needs speed, and then have routines that perform more administrative type roles in Main RAM. The GPU will run roughly 10x slower when running code from main RAM, but if it's only a relatively small amount of code that's ran once every frame or so, it makes it worthwhile overall.


    GPU in main is NOT a magic bullet, it is another tool/possibility that can be used to help in SOME circumstances.


    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.

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


    • Like 1

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

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

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


    • Like 1

  18. I don't think there is much chance of bricking a TI-99/4A with one. It really is as simple as you describe -- Just replace a chip and you're good to go. The only real chance you have of messing something up is cutting up the case for the VGA connector. A Dremel or other good rotary tool should work well though.


    As far as getting one, I'm looking to purchase some more myself, but they apparently aren't available until there are enough people signed up for the new batch. So, I'd recommend making your interest known: http://codehackcreate.com/store#!/F18A-V1-5-Video-Board/p/14022176/category=0

    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.


    Oh, no. Faaaar from it. The 8-bit Atari is vastly superior to Jaguar in this regard:


    1. You can have 4 MB of a full-speed unrolled code on 8-bit 6502 (via PORTB bank-switching)

    2. You can have 4 KB of a full-speed unrolled code on 64-bit jaguar

    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.


    Unfortunately, the allowed range of values for MOVEQ is only 0-31, so 32 colors are max. Of course, writing to GPU cache is always 32-bit, so you waste 24 bits (but, let's just say you are ok with this speed/size compromise for this particular case). I'm sure you noticed that you can't store a value to a memory directly. All storage is indirect via registers (hence the third instruction)



    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.


    That GPU-bugs file got so big (recently grew, because of the DSP-specific bugs), I actually have to scroll it. I think I'll have to buy a bigger TV because of the GPU bugs, mine's only 50"...



    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.

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

    • Like 2

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

    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.

    • Like 1
  • Create New...