Help fixing Witch

[KanedaFr]

Hi there,

 

The game I made for JagJam isn't working on real hardware, sadly.

It works without issue on VJ and bigP so I'm blind to fixing it.

 

I write this post hoping some of you could help figure what's happening.

 

I use JagStudio v1.11, sound engine u235.

Each screen has its own object lists.

 

18 hours ago, cubanismo said:

Witch loads from ROM or ABS, but the title screen graphics appear to be corrupted. See the attached picture. The first time it loaded after power cycling the Jaguar, all the graphics were severely corrupted (Everything was just colorful static. See pictures), even the intro sequence. Once it gets to the title screen, it just sits there. I tried 50Hz and 60Hz on both Skunkboard and Game Drive. I'd love to play this one when they get it working!

 

All my assets are on ROM apart my SFX (and my MOD, unpacked from ROM to RAM).

I only use 16 colors (4bpp) bitmaps but of course several CLUTs.

The title (and game) use 9 layers to create the parallax effect, each one using 2 objects to handle wrap on edge.

From @cubanismo tests, it seems it's not the culprit since corruption is even on logo screen : 2 objects -> my logo + animated claws

 

So I'm here, looking at my code and without ideas on what should I try to fix that....

😭 

😭

😭

😭

 

Since graphic corruption seems to be different at each startup, I only hope it's not  "data bus saturation" issue because I have no idea on how to fix it

 

 

 

 

PS: I don't thing it's a JS/Raptor issue but more a way I use them... and it's the reason I post on the JS subforum

 

 

 

[sjc]

11 minutes ago, KanedaFr said:

All my assets are on ROM

Does this mean they are specified as "ROM" in the assets.txt? If so, maybe try moving them to RAM, either explicitly in code or by settings them as "ABS" in assets.txt. That way the OP will be reading their data from (faster) RAM rather than (slower) ROM.

[KanedaFr]

1 minute ago, sjc said:

Does this mean they are specified as "ROM" in the assets.txt? If so, maybe try moving them to RAM, either explicitly in code or by settings them as "ABS" in assets.txt. That way the OP will be reading their data from (faster) RAM rather than (slower) ROM.

 

I could try to declare them as "ABS" apart packed one .....

But I don't see how I could unload/load them on demand ....
For example : there is now reason to keep the logo asset on RAM after skipping the logo screen... same thing for the title asset, only needed on title screen

 

To load ALL the assets in RAM will clearly fill it....and it would mean assets size is limited to available RAM size.

 

of course, I'll try...I'm only trying to understand how this works

[KanedaFr]

I'll follow the path suggested by @Sporadic on this post....

 

I don't really see how to "unload" them later but at least, I have more controls on how to load assets

and now, I won't distribute .abs file anymore since it seems it's not needed if you use ROM assets

[sjc]

3 minutes ago, KanedaFr said:

I don't really see how to "unload" them later

You don't really "unload" them, you just unpack the next lot of assets over the top of them (checking that nothing is still referencing them).

[KanedaFr]

...doing this means using a "big" buffer in RAM to unpack anything you want on it...and the time you need it

It would be really easy to point to the wrong address

 

oh..and I just understand i could no longer set object.gfxdata on appinit.s but only by code

not a big deal but it makes thing more and more complexe....

at this point, I wonder if I should not only declare N lists with N empty objects and set up everything by code

Edited November 2 by KanedaFr

[pps]

Maybe you have to many active objects. Esp. when there are objects loaded from ROM, I had same problem. My game ran fine with emulation, but not on real hardware.

Try to use not to many objects from ROM. 

[KanedaFr]

On the game part, probably but I doubt on the logo (2 objects) !?

 

On the credits, which is working, I have 3 objects + the text layers with particles...

[KanedaFr]

I made a first try with parallax assets on RAM not ROM.... let's see what happen

[Seedy1812]

Scanlines which has too much to draw will tear as you only have so much time per scanline to draw. Accessing images from ROM is not beneficial as its much slower than ram. A quick test would to set the address to  0 ( Ram ) and not Rom . Ok it may look like garbage but a quick check then you should no see any tearing

With Bubsy I had full 3 layers ( which would split horizontally and vertically ) that would be a backdrop and 2 alyers for the foreground - so Bubsy could run between the layers.

 

Edited November 4 by Seedy1812

[Zerosquare]

That's true, but it shouldn't happen if you're just displaying a simple logo. ROM accesses are slow, but not that slow.

Edited November 4 by Zerosquare

[KanedaFr]

Let see if you're on the right path @Seedy1812

 

Here is the one-layer-only version (ugly but we don't care now) :

if anyone could confirm it works or not on real Jaguar, i would make me happy (or sad...)

witch_inram_1.zip

[Seedy1812]

Are you using any sprite scaling ? Running under BigPemu  its fine but not seeing any background just a handful of small sprites. Without knowing what its meant to and what you ar showing us then We cant comment on what cold be wrong.
Dont use full screen sprite scalling on multiple layers as he Jag can't do this.

[KanedaFr]

yes, I use sprite scaling (you already saw the topic on AA about all the problem sI had under BigP  )
but not full screen of course (well full width but not full height)

 

What is the limit of the Jag on this part ? It's hard to know....
It seems we can handle a lot of objects but in fact "it depends"

But it depends on what ?  

 

A lot of objects....but only on an unique fixed background ?

Edited November 5 by KanedaFr

[Seedy1812]

Scaled sprites are CONSIDERABLY SLOWER to render as it has to draw things a pixel at time at least 8 times as slow

I would probably recommend you draw all the scaled layers into 1 non scaled full screen sprite.
As a test have the buttons 1 to 9 select how many layers of scaled spites are show and ask people let you know which number causes a tear / corruption of the screen and then you can set it to 1 lower

[KanedaFr]

12 minutes ago, Seedy1812 said:

As a test have the buttons 1 to 9 select how many layers of scaled spites are show and ask people let you know which number causes a tear / corruption of the screen and then you can set it to 1 lower

Great idea!!
I'll do that

 

I use 9 layers to great parallax effect
so if I merge them on 1 unique layer, I lost the effect....

But if I should do it, let's do it !

 

and scaling was used to limit ROM (now RAM) size but I didn't understand it will be 8 times slower   (I had more 2x in mind because of the last part of the doc part you joined)
I knew it would be slower but i was expecting a frame drop, not a gfx corruption....

Edited November 5 by KanedaFr

[Seedy1812]

No if you blit them scaled onto a layer which you draw at scale 1 then you don't lose the effect. You spend time blitting (into one ) or drawing ( multiple ).

Its like when you draw the credits screen. You can draw hundreds of sprites or you can blit the text onto a buffer and just draw that one sprite time after time after time.

 

Minter did similar thing in Tempest - do an effect on the screen and then blit the new one on top - repeat etc and you get funky effects 

Edited November 5 by Seedy1812

[pps]

18 hours ago, KanedaFr said:

Let see if you're on the right path @Seedy1812

 

Here is the one-layer-only version (ugly but we don't care now) :

if anyone could confirm it works or not on real Jaguar, i would make me happy (or sad...)

witch_inram_1.zip 152.26 kB · 4 downloads

It seems to work, but some glitches are there. e.g. some gfx garbage below the witch.

VID_20241105_175717.zip

[KanedaFr]

Thanks @pps

 

If I have glitch even on the main sprite, it clearly means I didn't understand how Jaguar works

Witch's assets are still in ROM so perhaps it explains the glitches...
It seems I had to use RAM only

 

2 hours ago, Seedy1812 said:

No if you blit them scaled onto a layer which you draw at scale 1 then you don't lose the effect. You spend time blitting (into one ) or drawing ( multiple ).

Its like when you draw the credits screen. You can draw hundreds of sprites or you can blit the text onto a buffer and just draw that one sprite time after time after time.

 

Minter did similar thing in Tempest - do an effect on the screen and then blit the new one on top - repeat etc and you get funky effects 

 

It means using the blitter (and its commands), right ? 
It would need an full screen object with gfxdata pointing to a buffer large enough, and blit my assets on the buffer, layer per layer ?
I read and re-read the doc about it  and it's still very hard for me to understand how to do it... 

I'll try again

 

If I either understand how to use the registers, what the difference between using N objects vs only one where you blit every asset ?
The when to use this way or this other one is a mystery for me...

 

PS: I knew I read somewhere Jaguar was able to rotate bitmap!

 

[KanedaFr]

thanks again for the video @pps, very useful => the glitch happens on first frame of the animation only
So probably when it reloads the asset....which makes the idea to use RAM only more and more obvious 

[Zerosquare]

- The blitter can perform some effects the object processor cannot (rotations, CRY interpolation, the "pixel explosion" effect in Tempest 2000...)

- The result of a blitter operation can be reused as a source for another effect (like the melt effect in Tempest 2000 @Seedy1812 mentioned above) ; you can't do that with the object processor

- The blitter can work in the background over several frames if needed ; with the OP, if processing takes more than one line duration (63 ~ 64 µs), you get visual glitches
- With the blitter, if nothing moves/changes, you don't have to run it again and there's no performance hit ; with the OP, even if nothing moves/changes, more objects means lower performance (as it starts from scratch on each line)

 

TL;DR: for sprites that move/change frequently, the OP is best. For more complex effects, or graphics that don't move/change often, the blitter is best.

[+CyranoJ]

44 minutes ago, Zerosquare said:

TL;DR: for sprites that move/change frequently, the OP is best. For more complex effects, or graphics that don't move/change often, the blitter is best.

 

You are also doing twice the work over the bus with the blitter.

Once to render he framebuffer (blitter), and once to display the framebuffer (OP).

[KanedaFr]

4 hours ago, CyranoJ said:

 

You are also doing twice the work over the bus with the blitter.

Once to render he framebuffer (blitter), and once to display the framebuffer (OP).

hmmm...

 

So is it a "good thing" to do this :

- update the background image full screen with Blitter (draw 9 bitmaps on gfxdata's content)
- display this background image with OP (no change apart the gfxdata's content itself)

every frame ?

or perhaps 1 frame update, 1 frame display ?

 

or i'll gain nothing ?

[+CyranoJ]

Don't know, not looked at your code. Staying out of the contests way.

[KanedaFr]

I'm clearly disqualified so I'm not part of the contest anymore.
Contest was a reason to jump on the Jaguar dev wagon, the cherry on the cake.

I can officially remove me of the contest if you want, I don't care now, I'm on the "I want it to work" way
 

And this could help futures developers too