Jump to content

Gorf

Banned
  • Content Count

    4,585
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Gorf


  1. Dont bother to waste your time...the Risc compiler is a pile of S$%t.

    Using a compiler to write code that should be in yuour local RAM

    is just plain silly anyway. Asm, Asm, Asm!!! ;)

     

    Now if I had the sources to that compiler, i'd fix it so it would

    write code according to the main RAM GPU code rules. Then it

    would make sense to have one. If you only plan to run from

    the local, a compiler will never be good for speed and efficiency.

     

     

     

    EDIT NOTE: I know becasue I am the one who gave that to Roine

    to post there. ;) Perhaps some day we will have those sources and

    fix it all up.


  2. ooh.....I may have to try that out,negated though....mwhahahahaha!

    I like spooky looking dark desktops. :)

     

     

    Yes, your right it looks much better as a negative.

     

     

    That does look pretty good. :) I prefer darker backgrounds personally, so that works well..

     

    ..Al

     

    Im in!


  3. Reading five pages of anything will do that to you :P

    I've always prefered large flat shaded polys as opposed to lousily textured shitty ones my self.

    a few of the 3D games refined to take out the 68000 or at least make it run more efficiently. Or heck, a few new homebrews could use these techniques. I expect to be playing Halo on my Jaguar by the end of the year :P J/K

     

     

    Actually the 68k is just a micro processor. It tells the video processor inside TOM

    what colors to use but the video processor really generates all the colors. The 68k

    just sends a value to a register inside that part of TOM, and the video portion of the

    chip knows how to turn it into a colored pixel on your screen. Now keep in mind

    that the video is built each frame by both the Object Processor Logic(OPL) and the

    Blitter. You can however, write to the frame buffer directly with the GPU, DSP and

    the 68k. There are also video line buffers you can mess with if you have a pair but

    you are really treating the Jaguar like a very advanced 2600 at that point. I know of

    a lad who has tried this and has had some interesting results.

     

    Let the OPL deal with the frame buffers. The OPL uses an object list in memory.

    That list represents a collection of windows much like sprites but very flexible

    and very powerful. In fact any thing you ever see on a Jaguar screen is the

    result of the OPL using this list to build windows onto your TV screen. These

    objects in the list point to a place in memory where the image data is stored

    and the OPL transfers to from the frame buffer to the line buffers which displays

    on your TV. The Blitter is usually used also to write to the main window object

    for polies and background effects like you see in T2k.

     

    The best way to operate the jag is without the 68k at all..it is really not necessary. It only runs at half the speed and is only 1/4 the bus. It really holds up a 64 bit bus just

    so it can move 16 bit data around. Even just it grabbing instructions is too much. The

    GPU and DSP in proper harmony are well more efficient and they way the designers intended to run the system. So far all of our 3D games are using an engine that is soley GPU and no more 68k hoggin up the bus. The 68k boots the sytem and then goes to bed.

     

    Hope that helps. :^)


  4. I think I would classifiy it as Hardware assited 3D but not fully 3D.

     

    The fact is, it makes for MUCH more flexible 3D as it is NOT hardwired.

    Again...even though textured games run horribly slow on the JAg, the

    quality is much higher than PS1 or N64. If you observe Hover Strike,

    you will see AMAZING lighting and mipmapping. Just unfortunately at 20

    fps....:(...again overuse of the 68k.

     

    I agree, it might be slower, but the graphics are superior to the PSX in almost every way. No clipping, warping, moving or anything of that nature.

     

     

    Dont forget 16 bit vs 256 usually. Shoot , I like the shaded games on the Jag. I love the

    unique and arcadey/cartooney feel they have. There is plenty of untapped potential still.

    Granted we wont be doing terraflops with the Jag but I know there is more to squeeze

    out of it. The color quality is also better on the Jaguar. It's much crisper.


  5. You should ask SCPCD about FPGAs, he is already doing great little things :)

     

     

     

    I have someone well experienced already. I just need the libs.

     

    The same guy who is working on Jaguar 2 ? How is progressing the project ?

     

    Yes but we have not been doing much at all on it with all the current work

    I have before me. I need a bigger crew.....5D Stooges? DOH! nah! we'll just

    have to do it ourselves....;)

     

    Fact is, ther are a few other folks helping us behind the scenes with a few

    projects like the debugulator.


  6. Yeah, SW2K had a lot of potential, I like those photon torpedos, they look like the rare earth phenomenon of ball lightning, as well as the fully textured ships that BS doesn't have.

     

     

    The key word is ships....there are many in BS...there is only one other in

    SW2K. Texturing one model on the Jag is not a problem. Another one or

    two more and you would see why you dont use t-apping so often.

     

    Then, on top of that, try to pull off even half the AI going on is BS in

    Space War. The pilots alone in BS are Harvard compared to the kinder-

    garten like play an AI of anything you will see Space War do. Still, both

    games are fun.

     

    chugg....


  7. For an unfinished title, it certainly was nice and it should have

    been released early. I do remember this being around for a while.

    Long before the fall. Too many times Atari chose to sit on things or

    put them on the back burner. Now I wont try to compare it with BS.

    It s a whole different planet form each other. It 's no BS but for a

    quick and dirty shooter though, its really cool.

     

    And if someone had the source we certainly could take a look at fixing it up.


  8. I have someone well experienced already. I just need the libs.
    Sorry, we (SCPCD and I) don't have them either.

     

     

    Yeah, no sweat man...no one seems to. It looks like its roll up

    the sleeves time. Im am quite confident in the guy I have on the

    project. Libs or not, I aims to see a Jaguar running at ludicrous

    speed(of course using Space Balls technology)! :D


  9. Pardon my ignorance - but wouldn't it have been a lot easier to go buy one of those small LCD monitors that take an AV input? You know, like you see parents putting in the mini-van for the kids to watch DVDs on?

     

     

    I use one of these for my Jag development. It good to do vertical

    monitor games on too.


  10. Well since this thread is way off topic...are either of you

    into FPGA stuff at all? I just got me a Spartan3e from

    Xilinx around Christmas and had pac man and the Astro

    cade running on it. Very cool, Mike J did those. Im looking

    to get the T&J chipset on it eventually. My hope is to fix

    a few bugs, and speed it up considerably. I am told by

    those who know that with the right xilinx and the right code

    we could imagine 200+mhz version of the chipset.

     

    Lotsa work..I have the T&J nets..I dont have a few

    old MOTOROLA/TOSHIBA libs required to simulate

    the chips for testing/debugging. May have to build

    them all by hand. DOH!


  11. Pardon my ignorance - but wouldn't it have been a lot easier to go buy one of those small LCD monitors that take an AV input? You know, like you see parents putting in the mini-van for the kids to watch DVDs on?

     

     

    And Jag can do RGB from the SV port which blows all others away

    in quality as that is the abolute direct signal most display devices

    break down to anyway. R,G,B, Hsync, Vsync. This is the REAL deal.


  12. AVP is a raycasting engine, not 3D. The Jaguar doesn't have 3D hardware. Take a look at ALL the rest of the 2D game machines of that time and you'll see that not ONE has a 3D game as fast as the Jaguar with the same pixel depth, resolution etc. The 3DO was the only console that competed, but it had 3D hardware. I've developed raycasting engines faster than AVP at that pixel depth on the Atari Falcon, but it took me a while for the optimizations, I've heard that the AVP programmer was rushed and pressured by Atari.

     

     

    You've heard correctly then. This was a common practice it seems

    at Atari at the time. I've have seen the AvP demo proto and it runs

    atwhat looks to be 30to60 FPS all the time. ALL THE TIME. That was

    before they used the 68k for AI. If they had been given the time to

    use the GPU for the AI, that game would have rocked a constant

    30fps at least.


  13. The Jaguar doesn't have 3D hardware.
    Not really true : the blitter can be used for hardware-accelerated texture mapping and gouraud shading (and possibly Z-buffering, but I'm not sure). But it's far from being a complete 3D chipset.

     

     

     

    I think I would classifiy it as Hardware assited 3D but not fully 3D.

     

    The fact is, it makes for MUCH more flexible 3D as it is NOT hardwired.

    Again...even though textured games run horribly slow on the JAg, the

    quality is much higher than PS1 or N64. If you observe Hover Strike,

    you will see AMAZING lighting and mipmapping. Just unfortunately at 20

    fps....:(...again overuse of the 68k.


  14. I recieved them as samples for one. You have to know how to talk to the salesmen, and it helps to have an actually registered business in electronics and gaming like I do. I have not recieved them yet. I told the salesman what I wanted, he said he'll send me a few different samples. I will take him up on the customizing offer. It is free.

     

     

    I'll fill yuo in as soon as I get them.


  15. It's being developed for Xbox Live Arcade, which is available for you if you have a Xbox 360 connected to the internet.

     

     

    No o never got one as I still never use my XBOX to justify a 360 purchase.

    :(


  16. I just can't see spending so much money on a game.
    I paid about $190 years ago for a BS 'Classic'. At the time I had a pretty decent job and I could afford it. I played it quite a lot and loved it; I thought it was a great game. Unfortunately, I ended up selling it when I lost my job. I actually only got about $140 for it when I sold it - but I figure I rented it for $50 and got a heck of a lot of play time out of it.

     

    Even now I'd probably be willing to pay $175, maybe $200 even for a copy. I can't really afford to go higher than that though... $400-$600 is way too rich for my blood.

     

     

    But if you had the money to piss away you and I both would go for it. :)


  17. It would be interesting to know how games on the Jag would have looked like if Atari had chosen not to include a CPU at all. I think there's a chance that they'd been better.

     

     

    A simple 'stop' intruction and disabling the 68k's interrupts is all that

    would take. Then it would be Tom and Jerry all by them selves.

    The trouble with this of course is that since the system was designed

    with a 16 bit host processor, for some reason(bad design again) the DSP

    needed to be the same width as the bus. The DSP is lightning fast internally.

    It is actually slower in some cases in main ram and extremely unstable with

    jumps, moreso then the GPU is.

     

    Since I got the main ram jumps and local to main jumps working the

    only time the 68k is awake it to init the vblank once per frame. that will

    be eliminted as well and once the game boots the 68k may only do an

    interlude in between levels or something if I ever to bother to use it at

    all again that is.

     

    The framerates in our games that wre once 15-25 and maybe 30 when

    most object were off screenare 30- 60 all the time and mostly 60. We

    are not done yet. This is using the very inefficient Atari sample renderer

    in the dev kit. DONT get me started on that thing...beautiful features it

    has but so inefficient. JagMod certainly cleaned it and sped it up a lot

    though. Before the main/local jump workarounds and JagMod's mods

    (now you no why he is the JagMod) to Atari's renderer we were lucky

    to get 5-15 frames a second. In all fairness the renderer docs clearly

    state that it was not intended for use in games and should only be a

    template for much more efficient code.

     

    Actually, I have seen sources to the cart version of Hoverstike.

    Except for the rendering, everything is pretty much done in the 68k..

    BZZZZZTT! I would love to get my hands on that source a move it all

    over to the RISC's( lots of work though). However, hat engine has much

    potential. The 68k , not the textures are what slows that game down so

    much.

     

    Gorf


  18.  

    AFAIK the 68K bus accesses are not optimized, they use a whole 64-bit cycle to fetch 16 bits, so 75% of the theoretical bandwidth is wasted.

     

    In other words, they spent many thousands of dollars making the other chips fast, and then they wrecked everything with a horrible bus interface when a good one could still have been simple.

     

    The 68000 bus interface, after all, needs to have one 16-bit data path connected to the 68000 and a 64-bit data path connected to the bus. How hard would it have been to do something like:

    On data read, perform the read using a 26MHz 64-bit bus cycle, latch 16 bits of the result, and then make it available to the CPU.
    On code read, if address bits 3-23 don't match last code read, perform a 64-bit bus cycle and latch all 64 bits.  On any data read, feed the 68000 the contents of the latch.
    On data write, latch the write address and data, and post the write at the next opportunity.
    

     

    Nothing complicated there--certainly nothing so fancy as the Jaguar's other chips--but the 68000's bus width utilization for a given execution speed would probably have been cut by a factor of at least three for most typical code, and by a factor of 8 or more for some other code (if a loop fits in a single 8-byte unit and does not access any data memory, it wouldn't use any bus bandwidth).

     

    What is a bit strange is that although the 68K has the lowest priority (so it shouldn't slow down other processors), tests show that disabling it improves performance.

     

    EDIT : SCPCD's theory is that since the 68k bus accesses last longer than other accesses (since it is clocked at 13 Mhz instead of 26 Mhz for the other chips on the bus), at least 1 cycle is potentially wasted each time it occurs.

    EDIT 2 : More than 1 cycle is wasted, since 68K are even longer than I thought.

     

    That could very well be what's going on.

     

    Zerosquare is right though. I know for a fact that this is essentially the case with the

    Jag from my own tests. IT does not belong in that system. Look at the cojag. What a

    difference in perfomance when you use a more suitable processor as the bus master

    (as in code master). Cojag is the same clock speed as the Jaguar. The only difference

    is more ram and the 68020 or r1000( not sue why they switched these around).

    My guess is the Jaguar chipset would operate most efficiently the way it was intended

    to be, by its very designers, without ANY other master CPU, unless it was on its own

    seperate bus. Shoot... the 68k on a seperate bus would have been fine. And again 64k

    would have been loads for any gaming ai.

×
×
  • Create New...