Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

JagMod

Members
 View Profile  See their activity

  • Content Count

    216

  • Joined

  • Last visited

Posts posted by JagMod

  1. Posted

    Ideally what should happen is that whenever the scale_x and scale_y values are both equal to 32, it should revert back to an unscaled bitmap automatically.
    Then you don't need the .scaled flag.

    e.g.

     

    Scaled: 

    sprite[sprBugIndex].scale_x = 64;
sprite[sprBugIndex].scale_y = 64;

     

    Not Scaled: 

    sprite[sprBugIndex].scale_x = ;
sprite[sprBugIndex].scale_y = ;

  9. Posted

    You could write a program to query/validate the format of the extracted Cinepak videos .

     

    *        In the chunky format, the film is broken up into temporal chunks of a
    *        specified duration. A chunk table near the start of the film gives the
    *        offsets to all chunk records which follow. Every chunk record begins
    *        with a sync pattern and contains a sample table giving the offsets
    *        relative to the base of the chunk of the audio and video data included
    *        within the chunk. 

  14. Posted

    If you're looking at the parser...

     

    This does not work:

    x        REGEQU    r1
    y        REGEQU    r2
    z        REGEQU    r3

     

    Error: syntax error; expected symbol

     

     

    however, this does work:

    xx        REGEQU    r1
    yy        REGEQU    r2
    zz        REGEQU    r3

     

  16. Posted

     

    Since the bug happens on high-frequency interrupts it should happen on the DSP early as the playback uses a 22kHz or 44kHz interrupt, right?

    But I think even though the ISA is quiet equal, the DSP is different in so many parts, that it is likely the bug is only in the GPU.

    If you just think of the bus width, memory size etc. . So I doubt they used the same RTL for both chips.

    I've been following this thread.

    I checked my code and I am doing what you were, not what DOOM is.

     

    I have two interrupts turned on in the GPU, one from the OP, the other from the Blitter.

    The OP interrupts once per vblank, the blitter interrupts ~10,000 times in a vblank.

     

    So maybe it isn't a frequency problem as much as it is which interrupts are being used.

     

    I've never used the timer interrupt with the GPU.

    You said you were doing 1ms timer interrupts. (1000 times a second)

    The Blitter is interrupting in the 60k to 80k times a second, and I've never seen this bug.

  18. Posted

    There are three rom variations.

    The 1mb has one version of the rom.

    The 2mb has two versions of the rom, 9000E version has some differences in the startup code..

     

    There is also a demo version of Cybermorph on the the Test cart, and there are many versions of the test cart.

  19. Posted

    Thank you for releasing it to the community. It's fairly obvious who the developers or programmers would be that could use a tool like this for good, and most likely you've got an idea who would use this in a harmful way.

    If there is some doubt whether a public release is a good idea, why not a limited time release to those developers who could use it and perhaps to Al etc or to someone who requests it with legitimate reasons and close it within a certain number of days so it's not just sitting out there?

    While you cannot control what they would do with it once they have it, it would be very easy to determine how it was leaked and by whom if it was a controlled distribution and that person could be avoided in future projects.

    Please don't mind the lousy spelling and thoughts, pretty wicked migraine dealing with some bad stuff.

    Developers and programmers don't need this tool, they can just write one themselves.

    • Like 2

  23. Posted

    No, I was just copying memory in a tight loop, one load, one store, and the gpu was slower running from main than the 68k.

    As soon as I put multiple load/stores into the loop, it got faster.

    But if you are writing something like a strcpy in C for the gpu, that's the kind of assembly the compiler will generate.

     

    I'm still a proponent for gpu in main ram, but you have to be careful what you are doing, not everything running on the gpu is faster.

  24. Posted

    Interesting. What code snippet was it? ( 'unroll loops' in gcc generally increases the number of instructions within a loop )

     

    Um...it was assembler using SMAC...it has nothing to do with gcc. GCC would not help at all, nor would

    any C compiler. Thre are going to be several places, no C compiler will avoid such a tight loop.

    You can tell the C compiler to unroll loops, but then as Owl has suggested many times, everything is a trade off.

    If you always unroll loops, now your code grows significantly.

  25. Posted

    Its the only example and I am pretty sure it was done using the SMAC assembler and not by hand.

    My guess is it has something to do with SMAC not handling something properly. My guess is it has

    to do with the broken JR instruction hadling.

    The problem was with smac and mac.

    The point is, there is no magical solution to fixing and optimizing all the quirks of the jaguar system.

    smac helps a lot by allowing code to be executed from main, but it doesn't keep the programmer from writing bad code.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...