OVERRiDE

So I am really curious how much code is custom for this mod? As in, is this just a ROM hack or actually full recompiling the DOOM source code? Main reason I ask is to see if you guys have the ability to add GDFS support to increase asset size ( once @SainT and @CyranoJ get things sorted ) and consider a digital-only build of this game to alleviate the ROM size limitations?

@SainT awesome news! And that certainly explains precisely what I experienced, the text files working was due to the small file size as you explained. I know you and @CyranoJ will get this bug squashed! Thanks again guys!

Awesome, you rock @SainT!

@SainT thank you for making this thing a reality! Sorry for the off topic, but have you had a chance to look into the GDFS issue posted here? Would it help to post this in this channel instead? And thanks again for all of your efforts here!

Not sure you saw my comment on the other post You can cull the sprite when y + height < 0 Not sure I've seen this problem though

@trufun101 or @trufungames great to see you are still cracking away at this! But I do have to agree with CJ that your explanation was a bit confusing in terms of how you've managed to optimize the level rendering. I take it, you were previously drawing all sprites ( in their entirety ) every frame? But now ( based on the developer thread post and watching your video ), you are drawing them to the "framebuffer" using the font / particle layer, but only when the scene moves? I'm not entirely sure that is the best approach here, and I want to point out a few optimization techniques that make a huge difference, if you aren't already aware. Clipping. This is the processing of "slicing" up an image ( or polygon ) that is only partially within the view window before sending it to the rasterizer. This means we only send data that is within screen space to be rasterized to save on bandwidth. This should be done on large sprites in Jagstudio by making the sprite no larger than the screen plus a bit of padding for offsets ( regardless of how large the texture data is ), and then adjusting the gfxbase in order to scroll that texture as the scene moves. Culling. This is the processing of completely preventing sprites ( or polygons ) completely outside the view window from being sent to the rasterizer. This means if an object is not within screen space, do not send it to the OP for processing. This is done in Jagstudio by setting the "active" flag on the sprite. As an example of Clipping, I have a background sprite that is 1296x256 pixels. But I only define the sprite width and height as 368x240, as this covers the entire screen plus ~16 pixels on either side. The important part is to set the gwidth to the actual texture width. Example Sprite definition ( irrelevant attributes omitted for this discussion 😞 ; Background1 dc.l 1 ; (REPEAT COUNTER) ; Create this many objects of this type (or 1 for a single object) dc.l is_active ; sprite_active ; sprite active flag dc.l 368 ; sprite_width ; width of sprite (in pixels) dc.l 240 ; sprite_height ; height of sprite (in pixels) dc.l is_normal ; sprite_flip ; flag for mirroring data left<>right dc.l BACKGROUND1 ; sprite_gfxbase ; start of bitmap data dc.l 4 ; (BIT DEPTH) ; bitmap depth (1/2/4/8/16/24) dc.l is_RGB ; (CRY/RGB) ; bitmap GFX type dc.l is_trans ; (TRANSPARENCY) ; bitmap TRANS flag dc.l 368*240/2 ; sprite_framesz ; size per frame in bytes of sprite data dc.l 368/2 ; sprite_bytewid ; width in bytes of one line of sprite data dc.l 3 ; sprite_CLUT ; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit) dc.l 1296/2 ; sprite_gwidth ; GFX width (of data) Then every frame, I check to see if we need to move the texture within the sprite based on "camera" movement: void backgroundHandler(int *backgroundScrollX, int backgroundGfx, short scrollAmount, unsigned int *level_offset) { sprite[BGND_INDEX].x_ += scrollAmount; if(sprite[BGND_INDEX].x_ < -31){ *backgroundScrollX += 8; sprite[BGND_INDEX].gfxbase = backgroundGfx +*backgroundScrollX; sprite[BGND_INDEX].x_ = -16; } else if(sprite[BGND_INDEX].x_ > 0) { *backgroundScrollX -= 8; sprite[BGND_INDEX].gfxbase = backgroundGfx +*backgroundScrollX; sprite[BGND_INDEX].x_ = -16; } *level_offset += scrollAmount; } No for Culling, simply need to check the position of the sprite and make sure it is within screen space, and either make it active or inactive based on that. Here are some shots of this demo in action: Full disclaimer - this is nowhere near a playable demo, just intended to play with the idea of using texture atlas with Jagstudio. There are issues with the sprite alignment that I don't have time to adjust my hand for Jagstudio - to this extent if the MS-DOS sprites are already aligned for you, 100% go with that man. All that said, here is the full demo code, assets and binary for anyone morbidly curious to check it out. I am just providing it to show you the concepts mentioned above in action. fighter.zip

I actually thought the programming manual states that there is no framebuffer on the Jag, with some B.S. reason that this made developers write more efficient code lol. But in practice, I guess you could just allocate an address in RAM and write all of your rasterized triangles to that as a framebuffer, then display that framebuffer as 1 sprite using the OP? If that is the case, how is the blitter used? I imagine for faster writes of your rasterized triangle pixels to RAM? Or is the blitter necessary to write back to RAM from the GPU? I say this having experience writing 3D API's for other systems, but still trying to figure out how this was intended to work on the Jag.

Amazing how fast topics here go off the rails. @Cubanismo thanks for working on this! What are the chances you could include a demo of how to display a sprite using the OP from C code running on the GPU?

I don't believe Human is @ArneCRosenfeldt's first language

Looking at your code snippet I dont think you are asking the right question. If you want to move the sprite up, down, left, right do them independently. Doing them independently means they can be done in conjunction. Pseudocode: If(pad & JAGPAD_UP) y += 3 If(pad & JAGPAD_LEFT) x -= 3 If(pad & JAGPAD_RIGHT) x += 3

Yes, that is one possible way. In this case, bit shifting >> 1 achieves the multiply by 0.5 / divide by two (4-bit bitmaps) but way faster since its an integer operation - I use this heavily in my other project where there are multiple divide-by-two operations that need to occur per frame and yeah using floating point maths really slowed down the performance lol. Again this function I posted was really just a quick implementation that was not attempting to be optimized by any means. Anyway, some more screens of this little project playing around with Arcade assets on the Jag using Texture Atlas based Sprites... it really is a shame Capcom and the like never embraced the Jaguar!

Yes this is very good advice, I have alrrady realized this on one of my other projects. Without an FPU the m68k is VERY slow at floating point operations. GCC can make them work so it may not seem obvious at first, but if do enough flops per frame and you will immediately see the performance penalty. On other systems I've worked on, multiply by 0.5 is faster than dividing by 2... but that assumes an FPU. For the Jag, bitshift instead is exponentially faster. For the code snippet above, this function is only called twice per frame so it is not a performance concern at present

Hi There, Your post about attempting to port Mortal Kombat actually sparked my interest in seeing what the Jag can do for 2D fighters. It's a shame the Jag never got much in the way of top tier licensed franchises because the Jag can certainly produce visuals on-par with pretty much and 2D fighter from the 32bit generation. The real issue is ROM storage size, not Graphics Processing ability. Anyway, yesterday I started playing with some things and realized that it would be necessary to support Texture Atlus, not just simple vertical sprites. And with Texture Atlus, the sprite can animate in any direction - vertically, horizontally, even out-of-order meaning the frames do not need to be contiguous. The Jag is certainly able to do this via Raptor / Jagstudio, but maybe not natively as it does with Vertical Sprites ( @CyranoJ please correct me if there is a native way ). Basically, you need to track your s,t co-ordinates as well as the width + height of each frame within the texture. From there, you can offset the graphic base address for the sprite by s * (texture bit depth multiplier) + t * gwidth. You also need to store your original gfxbase because this will now change between frames. Example, your sprite is located at pixel (s,t) 16,16 in your texture and the texture bit depth is 16, and your texture width is 512. sprite[i].gfxbase = originalGfxBase + (16 * 2) + (16 * 512 * 2) I've been able to easily get Texture Atlus working on the Jag using this method after 2 hours of playing around yesterday. The only caveat I see is that the t co-ordinate MUST be on a 16 pixel boundary, otherwise it will be rounded down to the nearest 16 pixel index. These screens are using the full Arcade Sprite sheet for Captain America from Marvel Vs Capcom, which is using this Texture Atlus approach I am describing. Again this is only a very quick implementation for my testing, but here are some code snippets that may be of interest to you. I am considering making a short tutorial to go through in further detail if there is any iterest struct animationFrame { int width; int height; int x; int y; }; void animateFrame(unsigned int spriteIndex, unsigned int frame, struct animationFrame animationFrame[], float mulFactor, int y, unsigned int base) { sprite[spriteIndex].y_ = y - animationFrame[frame].height; sprite[spriteIndex].width = animationFrame[frame].width; sprite[spriteIndex].height = animationFrame[frame].height; sprite[spriteIndex].bytewid = animationFrame[frame].width * mulFactor; sprite[spriteIndex].framesz = animationFrame[frame].width * animationFrame[frame].height * mulFactor; sprite[spriteIndex].gfxbase = base + (animationFrame[frame].x * mulFactor) + (animationFrame[frame].y * sprite[spriteIndex].gwidth ); }

If I had to guess, likely September. My free time to work on these projects is limited, and next month I will be out of state for 3 weeks and will not have my personal workstation with me so this project will not make much progress in August.

Thanks! PM Sent! Making good progress on this project. Pushing huge sprite lists and working on real hardware. Still a few issues I need to root cause before I am able to call this POC complete, but the most basic mechanics are in place. The player can lock-on to enemies and rapid-fire at them simultaneously 😃