Tempest is possible

[CunningFellow]

Thanks,

I'll have a look at the cycle counts on the last line. Probably just me miss counting as I changed things and the mode grew.

I had not really counted the whole thing since fairly early on in the development. Since then I had just subtracted NOPs as I added instructions.

Its good that the compile on linux is as easy as that. So you added an architecture telling it was a Mega644 and changed the gcrt1.S to gcrt1.s

I'll do that in the repo.

[Jubatian]

No, even adding that kludge of define was unnecessary. Simply changing that ".S" to ".s" solved it all. Stupid. If I did that first, it would have worked all right.

[CunningFellow]

Did you change the .S to .s in the file system or .s to .S in the makefile ?

I think the way to do it is probably in the makefile to .S

as I found out today there is a different between .s and .S

.S is like a .sx where the C preprocessor is run across the file first.

[Jubatian]

???

In Linux this would be the first time I experienced some feature tied to the case of a filename extension. But if ".s" files weren't ran through the preprocessor, the whole kernel wouldn't even compile, it uses that feature like everywhere. I changed in the filesystem, and checked with grep whether anything referred to it as ".S", but as I remember I only found such in a comment (not fully sure though, I could have fixed one and forgot while playing the game).

OK, I found it in the gcc manual (Man pages are great... You don't need to crawl packets through shitty wifi to get them... It could have took half an hour that way). The Uzebox kernel ensures them being compiled proper with the "-x assembler-with-cpp" flag. I guess the make in Tempest's source also has it set up this way, for all assembly files (sorry for guesses, didn't want to check it out now, having some experimental mess on my git workspace).

[CunningFellow]

D3thaddr3r, Uze,

Something went funny when I integrated this into the main source tree.

The 1/2 the sounds seem to be missing or don't play correct volume.

Is there something different with the "sound engine" files I had previously and the ones in the main kernel ?

[uze6666]

At what date was it fine? I can compare the source tree since some fixes was made with Artfox for his game.

[CunningFellow]

It is hard to put a date on it.

The kernel I was using was several years old. Sometime earlier this year you did some changes to enable MOD playback and some sound priority stuff.

They where not in the main branch at the time and I was given them in a ZIP file and I added them to my source tree.

So I am not sure what has gone wrong.

Maybe if D3thAdd3r can compile it OK, he can compile it without the music to start with and see if his in game sounds are still correct and that would be a starting point to find the problem.

[D3thAdd3r]

I didn't get time to look into this yet but I will try it soon. That sound priority system might be the culprit, it was posted somewhere here. I will try adding that back to be sure. Then too, what might have changed with the race condition brought to light in the game "Bugz"?

[Artcfox]

Can you post the kernel source that you used to compile it against? That could help narrow down the date range, and then it would be possible to run git bisect in order to discover the exact commit that breaks the sound.

[CunningFellow]

I just looked at doing a stippled gradient on the "2000"

Probably not going to happen. Takes >200 bytes of flash to do the "change pallet per scanline" stuff to make the different greys.

Single colour 2000 is how it will stay for now.

I will look at a more vibrant "game over" screen now. See if that can be done without a huge flash cost.