Misc KOS related issues

[BlueCrab]

Yes, I've been looking that over. The PVR code does indeed use two buffers. So the video code should definitely not be mixed with the PVR code, but it's still good. The changes I made for video.c make it simple to use multiple buffers for simpler 2D CPU rendered programs... of which there are quite a few. It won't interfere with the PVR code because you don't mix the two - you either use one or the other.

The thing is that it is still completely possible to mix and match the two, and use both 2D stuff (drawing to the framebuffer) and the PVR 3D stuff at the same time. It may be difficult, but its not THAT hard to do.

Except that KOS provided the functions to do that... they just weren't implemented. I simply made what was there work the way it was originally intended.

They were implemented just fine, you didn't change the implementation. You only changed the data they were working with. Which can be done outside the KOS tree so that no issues come up with projects that may rely on things being exactly as they are now. This is why we don't change stable/accepted code paths -- we don't want to break other people's code that relies on things being the way they are (whether that way makes sense to you or not).

Yes, that's true as well. I was just pointing out that SDL also ran into that problem with the double-buffer not being properly supported. I'm sure many people look at the vid_flip and think it would be great for their project, only to find it doesn't work. PVR is rather complicate for a simple double-buffer. Look at it this way - if all you needed was simple buffering, isn't it better to give something simple?

I doubt that anyone really looks at vid_flip, because almost nobody touches the 2D video code any more. If they're going to do 2D, they usually either use the PVR API (or one of the supplements to it, like parallax or tsunami), or they use SDL. I've seen pretty much 0 new homebrew programs in the past year that directly touch the 2D framebuffer because its exceedingly slow to do stuff with. I find it much simpler to use the PVR to do my rendering than to do it in software, and much faster too.

"If it ain't broke, don't fix it." Sorry, but it's broke - I fixed it. The point of making something open source is so that people can fix it. I'll post a diff and let others decide if it's stable and good enough to warrant inclusion in the main repo.

Its broke in your eyes, but not in mine. Also, your "fix" may break tons of other people's code. Do you want to be responsible for fixing other people's code too, just to "fix" this "bug"? If you really want to use vid_flip, do what I said before, make your own copy in your program of the vid_mode_t you want to change, and change it. It does not require a change to the video code that may have consequences for countless other people.

Accepted, yes. Proper, no. It still doesn't give you a draw buffer - it gives you a pointer to the VISIBLE FRAME BUFFER.

It doesn't give you a pointer to anything, it sets the visible framebuffer.

It's not more sane - you don't get a draw buffer and you have to track all the buffers yourself. That's just ASKING for problems. My changes make it simple and fool proof.

1. Call vid_set_mode()
2. Draw through dvram_s or dvram_l
3. Call vid_flip(-1)
4. Loop to 2

Look at how simple that is... it's virtually impossible to screw up. Perfect, simple, FAST, 2D multi-buffering. You can't EVEN compare using vid_set_start() to it at all.

Its not that hard to keep track of 2 buffers, really its not. Also, as I said, if you want to use vid_flip, set it up in your code with a simple call to vid_set_mode_ex. Don't risk breaking a whole bunch of other people's code just to fix something that you don't like.

I don't want to seem like the bad guy, or the mean maintainer here, but I've made changes that have had unintended consequences before. I don't like to have to figure out what broke people's code when its unnecessary to make the change in the first place.

[JLF65]

wow that's a discussion! AWHEAUwehUAweAUWeh.
JLF65 is right, kos is open and he can do whatever he want's, then we can decide if it's useful or not to some project. I think that kos can be split in different branches for different purposes, ie an small kernel without net, pvr can be used for software rendered projects -in this way more memory can be available-.
There's a lot of people using software rendering (including me) for small projects and this can be significant for improve speed and quality in games.

I appreciate that this kind of discussions are taking place: it means that the scene isn't dead and that there's a lot of things to improve in kos, sdl, and all the libraries available.

JLF65: Thanks for the doom, i'll test it. The speed that you got looks impressive!
I hope that you can release a working kpit sh tools for dc/kos, it will be significant for the scene.

Well, there's a patch file on the mail list for making a proper gcc 4.4. I'll probably try that first.

I don't want to split kos, just make a few little improvements to one area. As far as I can tell, it doesn't affect the other areas, and it really makes one area better than it was.

It may not make it into the main repo, but people are always free to make the changes themselves like I did, especially if they find it useful. It was just the thing I needed for Doom. It's a prime example of an app that would benefit from the change.

[BlueCrab]

I have an idea of how to fix both the issue that you wish to address, JLF65, as well as making sure that the normal code-path doesn't change for anyone unsuspecting. I'll try to throw something together later on today with this idea that I have, and hopefully it'll do exactly what you want it to.

[JLF65]

I have an idea of how to fix both the issue that you wish to address, JLF65, as well as making sure that the normal code-path doesn't change for anyone unsuspecting. I'll try to throw something together later on today with this idea that I have, and hopefully it'll do exactly what you want it to.

Cool - I'll try it out once you have it ready. I got 4.4.0 compiling yesterday... that was fun. The patch on the mail list worked great, but it was everything else that was the problem.

If you compile 4.4.0 for ARM, you don't get libgcc anymore as all-gcc no longer includes libgcc on ARM targets. The suggested all instead of all-gcc also segfaults for the ARM target (common problem with 4.4.0). I had to go all-gcc and then another pass with all-target-libgcc to get libgcc for the ARM toolchain. Also ARM related - binutils 2.19.1 won't compile for ARM without being patched first. I made a diff file for that along with my changes to video.c and biosfont.c.

I've attached a zip of the diff files for video and biosfont (in case anyone wants to look at what I did), and a new Makefile and diffs for putting in kos/utils/dc-chain/ to compile 4.4.0. It gives a complete new set of SH and ARM toolchains. The kos and kos-port compile fine, but I noticed when compiling Doom that lwip has a some includes that don't set the packed attribute properly, so it's ignored in those includes which may cause programs using lwip to fail.

[BlueCrab]

The kos and kos-port compile fine, but I noticed when compiling Doom that lwip has a some includes that don't set the packed attribute properly, so it's ignored in those includes which may cause programs using lwip to fail.

Its just a simple warning that 8-bit values don't need to have the packed attribute set on them (they are always "packed" as it were). It shouldn't hurt anything.

[JLF65]

Its just a simple warning that 8-bit values don't need to have the packed attribute set on them (they are always "packed" as it were). It shouldn't hurt anything.

Hmm - that's not what I read in threads about it when I googled for the warning. I may need to do more googling to see if the first few hits were just being overly strict. My own packed attributes went through without warning. It's just the lwip includes that generated them. I don't have any network adapters for my DC, so I can't really check it either.

[Guaripolo]

well i've looked at the game (just in nulldc, i have not bba) and it looks nice, i don't know if music is right (nulldc doesn't run that fine in wine) but it is working ok.
I still think that pvr rendering looks better in dc (i don't know why), just check out the Edge port of Chui (DreamEdge), maybe you should check out pvr rendering.
Finally, is good to see people working in new dc homebrew!

[JLF65]

well i've looked at the game (just in nulldc, i have not bba) and it looks nice, i don't know if music is right (nulldc doesn't run that fine in wine) but it is working ok.

The music is DEFINITELY wrong... still trying to figure out why since it's the same code as in the AROS and PSP versions. The SFX are fine... which eliminates the audio playing routine as why the music is bad.

I still think that pvr rendering looks better in dc (i don't know why), just check out the Edge port of Chui (DreamEdge), maybe you should check out pvr rendering.
Finally, is good to see people working in new dc homebrew!

This was only meant to be a test of KOS and the dev tools. I wanted to make sure I could compile and run stuff. If I were really trying to do a Doom conversion (not a test), I'd be converting PrBoom+, not this old version of Doom.

Doing this did teach me a lot about the DC - getting controller inputs, playing sound, setting the video, how threads work on the DC, timing...

[BlueCrab]

Multi-buffering stuff was committed to the KOS repository as r647. It doesn't work exactly as JLF65 proposed. The implementation that I committed adds a a whole set of video modes that support 4 framebuffers, while leaving the old versions intact. They can be selected directly with the newly provided display modes (the specific modes that end in _MB), or by using a generic display mode ORed with DM_MULTIBUFFER.

Since the video modes must be set explicitly, vram_s and vram_l will always point to the "drawing" buffer (as long as vid_flip is used, i.e, the next framebuffer that would be selected by a vid_flip(-1), much like dvram_s/dvram_l in JLF65's original modifications). As a result of this, there is no point to dvram_*, and no need for the second clearing function.

I believe that this is a sane and safe compromise between the two extremes (leaving it alone and changing everything for multi-buffering with no regard for possible consequences). I've tested everything out with both PVR-based rendering (not specifying a multi-buffered video mode), as well as with software rendering (specifying a multi-buffered video mode), and haven't seen any problems.

[JLF65]

Multi-buffering stuff was committed to the KOS repository as r647. It doesn't work exactly as JLF65 proposed. The implementation that I committed adds a a whole set of video modes that support 4 framebuffers, while leaving the old versions intact. They can be selected directly with the newly provided display modes (the specific modes that end in _MB), or by using a generic display mode ORed with DM_MULTIBUFFER.

Since the video modes must be set explicitly, vram_s and vram_l will always point to the "drawing" buffer (as long as vid_flip is used, i.e, the next framebuffer that would be selected by a vid_flip(-1), much like dvram_s/dvram_l in JLF65's original modifications). As a result of this, there is no point to dvram_*, and no need for the second clearing function.

I believe that this is a sane and safe compromise between the two extremes (leaving it alone and changing everything for multi-buffering with no regard for possible consequences). I've tested everything out with both PVR-based rendering (not specifying a multi-buffered video mode), as well as with software rendering (specifying a multi-buffered video mode), and haven't seen any problems.

Yes, that does sound better. Backwards compatibility is guaranteed, and the multi-buffer modes always point to the next draw buffer with the "normal" pointers. Great idea.

Did you look at the changes I propose for biosfont?