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.
Moderator: Mask of Destiny
It's a demo that I'm working on getting ready for the 26th of May, so yes there will be a demo.
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.Sik wrote: ↑Thu Mar 15, 2018 10:12 pmYou 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.
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.Miquel wrote: ↑Fri Mar 16, 2018 3:36 pmIf 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.
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.
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.
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?Sik wrote: ↑Sat Mar 17, 2018 5:47 pmIt 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.
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.
Thanks!