SpritesMind.Net

Miquel wrote: Wed Mar 14, 2018 3:18 pm Is there any possibility of a demo?, even if it is just a really small one.

It's a demo that I'm working on getting ready for the 26th of May, so yes there will be a demo.
But, yes, I might actually release something before that. A pre-demo demo, of sorts. Depends on if I can keep up with the schedule or not.

You can probably start by moving explosions out of the sprite engine autoallocation (at least the common smaller ones). They show up all the time, probably don't take up that much video memory, and in fact there's a high chance the same sprite will show up 2 or 3 times in the same frame when something starts exploding.

Essentially, if it's "small and common", you'll want to keep it in VRAM instead of allocating it every time it shows up.

Sik wrote: Thu Mar 15, 2018 10:12 pm You can probably start by moving explosions out of the sprite engine autoallocation (at least the common smaller ones). They show up all the time, probably don't take up that much video memory, and in fact there's a high chance the same sprite will show up 2 or 3 times in the same frame when something starts exploding.

Essentially, if it's "small and common", you'll want to keep it in VRAM instead of allocating it every time it shows up.

Yes, I think I will come to that conclusion as well. "Normal" explosion, gold and the enemy bullets are the first to be evaluated. Pretty sure they all fit in there without taking up much vram.

On another note, started the game on real of for the first time this week, it crashed.
Happens after "a while", and "a while" is different each time. Probably has to do with me now the tile scroll instead of plane scroll. Also I've been changeing CPU to DMA in a lot of places without checking the consequences of it...

Also, the fun-with-bonus/shop/between-stage screen is taking form. \o/



Our hero is supposed to be standing on that pillar and spewing out its gold in a very graphic manner. Well, that's all I know of it...haven't figured out the juman interface for the transmutation-of-gold part, yet, though. Or the design of it, for that matter.

If you explain how it crashed perhaps we can help resolve it.

In my experience Video DMA doesn't crash but simply doesn't work instead. Do you know that data must be aligned to 16bit? 1byte data doesn't count. If the game simply stops probably is due to cpu problem, catching and displaying exceptions offers some help it that regard.

What I do is to test the advances weekly, every Saturday, on real hardware.

Is the crash a hang, or is there some kind of error message (like address error)?

I know BlastEm has caught some of my hangs, like when my game tried to read cram in write mode. So give that a try if it is hanging.

Miquel wrote: Fri Mar 16, 2018 3:36 pm If you explain how it crashed perhaps we can help resolve it.

In my experience Video DMA doesn't crash but simply doesn't work instead. Do you know that data must be aligned to 16bit? 1byte data doesn't count. If the game simply stops probably is due to cpu problem, catching and displaying exceptions offers some help it that regard.

What I do is to test the advances weekly, every Saturday, on real hardware.

I test it several times a week, normally, but this time it was almost a week ago because the tv is always occupied...like it is now, which hinders me in the trouble shooting this thing. Will check for alignment issues, thanks! I do export my own asm files so it could maybe be an issue. But I don't think so, come to think about it I just use dc.l and dc.w and I do have .align 2 at the start of those files. But I'll double check that.
But I know what areas I've been doing changes in, so I think I'll figure it out, eventually.

Grind wrote: Fri Mar 16, 2018 3:53 pm Is the crash a hang, or is there some kind of error message (like address error)?

I know BlastEm has caught some of my hangs, like when my game tried to read cram in write mode. So give that a try if it is hanging.

It did both hang and crash, actually. I just now tried it in Blastem, thanks for the tip, but the problem don't seem to pop up there either. Would have been nice if it had, would made the trouble shoot loop faster.

As soon as the kids are in bed I'll try the versions, one of them is bound to work since I've removed almost all of this weeks changes in one of them.
But I'm guessing on the change to tile-scrolling to have produced this issue. It's the only thing added to the main loop that does something completely new.

Thanks!

Without explaining what happened is just guessing, but ".align 2" is not enough, you can also break alignment with a pointer (register).

Miquel wrote: Sat Mar 17, 2018 11:44 am Without explaining what happened is just guessing, but ".align 2" is not enough, you can also break alignment with a pointer (register).

Can this happen even if I don't manipulate pointers directly? Sure I do ptr = &pointedto; But I then never do ptr++, or something like that.
And "pointedto" will always be word aligned if it's a C variable (even u8), right?

I've now changed all DMA to DMA_QUEUE and now I can't replicate the error (easily, at least). Which, is good, I guess?
But I can now see that the background layer sometime get tiles that are totally wrong...well, still trouble shooting.

It can't be an unaligned pointer because:

1) You'd get an address error consistently
2) BlastEm would catch it

In fact, quite surprised that BlastEm doesn't catch anything... that you bring up that switching how DMA works makes me think you may have been unlucky and hit certain DMA bug right in the worst spot possible (the DMA controller in the VDP is buggy and if your timing is unlucky it will cause the system to completely hang up by never letting go of the bus). As far as I'm aware we still don't know the exact trigger conditions for this bug, since in the vast majority of the cases you'll never trigger it even if you ignore all of the warnings in Sega's docs.

Sik wrote: Sat Mar 17, 2018 5:47 pm It can't be an unaligned pointer because:

1) You'd get an address error consistently
2) BlastEm would catch it

In fact, quite surprised that BlastEm doesn't catch anything... that you bring up that switching how DMA works makes me think you may have been unlucky and hit certain DMA bug right in the worst spot possible (the DMA controller in the VDP is buggy and if your timing is unlucky it will cause the system to completely hang up by never letting go of the bus). As far as I'm aware we still don't know the exact trigger conditions for this bug, since in the vast majority of the cases you'll never trigger it even if you ignore all of the warnings in Sega's docs.

I actually got a crash (on real hw) and with a readable address error, now! I've gotten this black screen before, but most of the info has been faaaar to the right, so that I couldn't read it. What's up with that?
But this clearly says something. A0 is the obviously unaligned, right?
Don't know what's happened, though. Any ideas?



Maybe I shouldn't say this, but I've been running the ROM that had crashes all of the time on real hw (a couple of days ago) and that is actually not giving the error anymore. Strangeness is in the air. Ghosts?

OK that's definitely a bogus pointer... Actually, now I wonder if you're accidentally touching the 32X area or some other address range that causes the bus to lock up (・～・)

Sik wrote: Sun Mar 18, 2018 1:49 pm OK that's definitely a bogus pointer... Actually, now I wonder if you're accidentally touching the 32X area or some other address range that causes the bus to lock up (・～・)

And another one! Finally I'm getting lucky with these. Program counter seems to be in the same area, I'm sooo gonna crack this today.

That 4E75 in the address implies it tried to get its address from somewhere in the code (4E75 is the opcode for RTS).

Sik wrote: Sun Mar 18, 2018 11:58 pm That 4E75 in the address implies it tried to get its address from somewhere in the code (4E75 is the opcode for RTS).

Thanks!
Looking at 42C0, there's a BTST on D0. That doesn't make sense, does it?

FUNC is a code about the instruction / memory access type, ADDRESS is the accessed memory address which asserted the exception and INST is the instruction code doing it. So here INST = 3238 = MOVE.W xxx,xxx instruction which tried to access a odd address --> BUS error
From the PC you can probably trace back which method asserted it.