JagMod

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 = ;

Alien vs Predator

Dino Dudes

Trevor McFur

Raiden

Wolfenstein 3d

Tempest 2000 front and back.

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.

Not sure why you would want to convert back, since Cinepak is a lossy video codec.

JagCinePak.exe version 1.53 07/29/20 ===================================== Fixed 32bit overflow. Longer movies with high audio sample rates cause the sample count to exceed 2^32 Thanks to Cubanismo for finding this bug. Download new version of JagCinepak

Faran was also involved with: Evolution: Dino Dudes Tiny Toon Adventures Trevor McFur in the Cresent Galaxy

One more small suggestion for rln. Change from malloc() to calloc() in rln.c to expose several bugs.

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

Here you go... 80001611.DWG Online Viewer

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.

Is there such a thing as a good baseball, golf or tennis game?

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.

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

Someone beat you to it. lol, that sneaky bastard! Wasn't me.

All three of those labels have different roms. Two are 2mb, the third is 1mb. The two 2mb carts are different.

You're missing one of the labels. All three labels

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.

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.

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.