MK update running on real Hardware!

[walter_J64bit]

 

[+Biff Burgertime]

Oh cool, an update not locked behind a paywall.

[KidGameR186496]

I gonna give this a shot in BigPEmu Finally we have a demo of Jaguar MK1

[Gedalya]

1 hour ago, Biff Burgertime said:

Oh cool, an update not locked behind a paywall.

I believe all of his updates are made available to the public, those who pay simply get to know sooner rather than later. 

[+CyranoJ]

Bit convoluted and confusing.  Anyone who has read the RAPTOR/JS manuals would be completely lost listening to that.

 

Nothing in the "new camera system" section explains why the object processor bandwidth is lower, as everything mentioned results in a net0 difference in display. Not sure what "and then I only redraw the screen here" was about either, its a simple GDIWTH/BWIDTH window into the whole backdrop, can very easily do the same with Y-axis.

 

Anyway, as I've said many times before, if the end result is fun and playable, who gives a f**k how it got there?

 

Hopefully plays well at the end! 

[SlidellMan]

@trufun101 You did the right thing by going with smaller sprites for the time being.

[+grips03]

Yes smaller sprites are way better.  I think the sprites are still a little too thick.

[agradeneu]

I think the SNES uses tilemaps to fit all backgrounds into RAM? It only has 128Kbytes, while Jaguar has 2 Mbytes.

Nontheless he appears to run into RAM limits.

[agradeneu]

1 hour ago, grips03 said:

Yes smaller sprites are way better.  I think the sprites are still a little too thick.

He is aiming for "arcade perfect", which translates into "as close as he could get".

 

Jag res is a little lower than the Arcade game, but not that much. Sprite size seems adequate now, I would be disappointed if he would lower them to SNES level. SNES has lower res than Jag btw. 

 

I still believe he could push the colors to 32 indeces per sprite. Would give the Jag version a slight edge over the others. 

 

Edited February 16 by agradeneu

[agradeneu]

7 hours ago, KidGameR186496 said:

I gonna give this a shot in BigPEmu Finally we have a demo of Jaguar MK1

Iam a backer too. Where is the demo?

[agradeneu]

1 hour ago, grips03 said:

Yes smaller sprites are way better.  I think the sprites are still a little too thick.

SNES has an 256x224 res, so images/sprites are stretched slightly for the 4:3 format. That is why it looks a bit thinner in the source image.

[Rick Dangerous]

Please put me on the pre-order list for two copies.  Thanks you. 

[+cubanismo]

19 hours ago, CyranoJ said:

Nothing in the "new camera system" section explains why the object processor bandwidth is lower, as everything mentioned results in a net0 difference in display. Not sure what "and then I only redraw the screen here" was about either, its a simple GDIWTH/BWIDTH window into the whole backdrop, can very easily do the same with Y-axis.

Yeah, I'd be very concerned if scanning out a window into a large 'sprite' took more bandwidth than a full small 'sprite.' Maybe there were page misalignment issues before or something? I don't question that changing things fixed... something, but it doesn't seem to be adequately explained. FWIW, I run into this all the time, where I find a fix, work backwards to convince myself it is the right fix, and then upon getting it reviewed or talking about it with someone else, realize my reverse engineered explanation is completely bogus. Usually the fix is still right, but I just misunderstood the nature of the problem and need to reevaluate why the fix worked if I want to feel good about its robustness or be able to apply the knowledge gained from working on the fix to other issues in the future.

[OVERRiDE]

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

1. 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.
2. 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

 

[Sporadic]

Yeah, scrolling a backdrop in that manor is also shown in the "imagescroller" example project supplied with Jagstudio.