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.Quote:
Originally Posted by JLF65
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).Quote:
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.
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.Quote:
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?
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.Quote:
"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.
It doesn't give you a pointer to anything, it sets the visible framebuffer.Quote:
Accepted, yes. Proper, no. It still doesn't give you a draw buffer - it gives you a pointer to the VISIBLE FRAME BUFFER.
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.Quote:
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. :cool:
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.
