Time For Dynamic Linking?

[Pickle]

I think with 3 handhelds its time for development to start using dynamic libs, that way one binary could be compilied and run on all 3 handhelds.
I believe the best way to start this is to kick off open2x (which is close to a release anyways) with dynamic library support and start recompiling the apps that could support this. If we can get this done it will save time and space (archive and sd card)
Any other ideas?

 

[Squidge]

I've already recommended dynamic linking for the Pandora so the support libraries can be updated without having to recompile the main app. If we could start doing it on the gp2x under Open2X it would be excellent. Just need to have an alternative to Rlyeh's MiniSDK (or the SDK in it's own library so compatability layers can be implemented for other platforms).

 

[Pickle]

I've already recommended dynamic linking for the Pandora so the support libraries can be updated without having to recompile the main app. If we could start doing it on the gp2x under Open2X it would be excellent. Just need to have an alternative to Rlyeh's MiniSDK (or the SDK in it's own library so compatability layers can be implemented for other platforms).

I know you have, and im glad you responded. I guess what I had in mind was the highler level librarie like SDL and eveything open2x already builds.
With the miniSDK are you suggesting a standard low level API be designed to work for all 3 devices?

 

[Squidge]

With the miniSDK are you suggesting a standard low level API be designed to work for all 3 devices?

It would certainly be nice, but I don't think such a thing would happen. I'd say the best we can hope for is a lib for each platform that addresses the specific features of that platform, and then eventually write the libs for the other devices, emulating features that are not available. We just have to be careful that we don't end up with 26 different version of the library to address specific features in certain applications, as that would defeat the point of it.

 

[Pickle]

With the miniSDK are you suggesting a standard low level API be designed to work for all 3 devices?

It would certainly be nice, but I don't think such a thing would happen. I'd say the best we can hope for is a lib for each platform that addresses the specific features of that platform, and then eventually write the libs for the other devices, emulating features that are not available. We just have to be careful that we don't end up with 26 different version of the library to address specific features in certain applications, as that would defeat the point of it.

Seems to me if someone took the time to code up some of the features for the other devices to add to the exisiting minimal lib wouldnt be much harder.
Maybe a little more work to make some things generic that could be, like for example the timer feature, there doesnt need to be 3 different timer access points just one. But the code that gets it done might have to be different.
I guess what i have in mind is one code base, but 3 different compilied versions.

 

[PokeParadox]

Well I'm all for this. I don't think I'll be able to get a Wiz... so if I can release a binary that works on Wiz too it would be nice.

 

[ldesnogu]

That's an interesting idea, but that wouldn't work if you use the DSP or the 3d accelerator or hardcode screen resolution.

 

[notaz]

But a small rlyeh's minimal-like lib which could do simple things (ones which are used most) would be nice. The lib could be made with GP2X, Pandora and Wiz in mind (and maybe GP32 too?), and would be 2D and performance oriented.

Here are some functionality that comes to mind:

• Read input in some unified way. It could return some bitfield of something, where you could check buttons with generic tests, suitable for all GP-like devices. Left, right, ..., L, R, action_north, action_west, ... This would not cover Pandora's keyboard, just the gamepad.
• Read USB joysticks
• Flip display buffers and get direct framebuffer pointer
• Wait V-sync
• Change resolution (using scaling services in the console, GP2X, Pandora and I assume Wiz can do that)
• Switch display mode (8/16/24 bit), set palette for 8bit mode.
• Turn frame buffer caching on/off, flush cache function for cached mode.
• Overclocking services. Special constants "default", "safe", "high", or direct MHz value provided.
• Volume control (for GP2X, mainly).

The lib would not cover platform specific stuff, like Pandora's DSP, GP2X's ARM940, etc.

I could volunteer maintaining such lib for GP2X and Pandora. That is of course if anyone is willing to use it. Somebody just needs to design a nice interface API, I could try to come up with something. It could be called libgp32x, for example

 

[ldesnogu]

Hum that looks like SDL, doesn't it?

 

[Squidge]

That's an interesting idea, but that wouldn't work if you use the DSP or the 3d accelerator or hardcode screen resolution.

I don't think that many apps will use the DSP, the 3D accelerator should be OpenGL, which can be converted for the Wiz, and software driven for the GP2X. Hardcoded resolutions can be fixed by the hardware scalers present in all three systems.

 

[notaz]

Hum that looks like SDL, doesn't it?

Inputs - those are not unified from what I've seen, different for every system (depend on how backed is ported). For GP2X, inputs returned depend even on SDL version being used!
While SDL can do some of the tasks, does it have overclocking stuff? Direct control over vsync? Framebuffer cache control? TV-out control functions?
What about people who don't like SDL?

 

[ldesnogu]

Inputs - those are not unified from what I've seen, different for every system (depend on how backed is ported). For GP2X, inputs returned depend even on SDL version being used!
While SDL can do some of the tasks, does it have overclocking stuff? Direct control over vsync? Framebuffer cache control? TV-out control functions?

Wouldn't it be better to split these functions into different libraries? Though I agree some of them should belong to an SDL-like lib.
QUOTE
What about people who don't like SDL?

What about people that won't like the new lib(s) API?

@Squidge I agree on your point, but your exe will also have to use only ARMv4T, that is no DSP like instructions, no NEON, no VFP.

 

[Pickle]

I see 2 situations going on here.
1. Minlib that is used for other higher libs
2. SDL type higher level libs

For number 2 its pretty much a no brainer that this type of lib can be extended to be supported across all 3 platforms.
For number 1, i think i coming up because higher level libs like Fenix are using it. This kind of an issue cause we have some overlap. For example minlib has timers, as does SDL. As some have mentioned before some like SDL where some like the minlib. A clean solution would be to limit minlib to very specific hardware features. I dont know if we could get away from that without cauing major headache. Personally I would like to see anything that couldnt be done in SDL be moved to the minlib.
One useful thing might be to analyze the usage of the more generic funcitons to see if any one actually uses them.

I think the lib could support the special features with the expectation the dev knoes he can only use it on that platform. Maybe there could be a common lib, and then specific lib for each device.

 

[Squidge]

So rather than a "Minilib" there would be a "HWlib" ?

I do think people should attack the hw less on Pandora and use libraries instead. For example, use "gettimeofday" (or SDL's function) rather than peeking hardware memory registers like Minilib did.

 

[Pickle]

So rather than a "Minilib" there would be a "HWlib" ?

I do think people should attack the hw less on Pandora and use libraries instead. For example, use "gettimeofday" (or SDL's function) rather than peeking hardware memory registers like Minilib did.

Yeah i think that sums it up pretty much. I just dont know if we could get everyone on board with it. I suppose we really would just need to get the high level lib maintainers to switch to using this new standard. Homebrew would be suggested to go this route, but is a free(dom) system so they can what they want.

 

[PokeParadox]

sounds good to me, to abstract things like overclocking and other things into a HWlib.

 

[Pickle]

sounds good to me, to abstract things like overclocking and other things into a HWlib.

I may if I have the time this weekend propose two lists of functions based of the current minlib.
Basically of list of functions to keep and a second list of functions to be abosorbed into other common libs i.e SDL.

 

[quasist]

Do not forget MIC input for Wiz/pandora. With function to get current membrane displacement (for ingame events), and another pair(?) to buffered recording (for music software).

 

[Lozrus]

Do not forget MIC input for Wiz/pandora. With function to get current membrane displacement (for ingame events), and another pair(?) to buffered recording (for music software).

If such a lib existed then I would certainly use it. I would also like to see some platform specific features though, such as the mic support, touchscreen and keyboard, with a set of properties that I could poll to see if these features were available. This way the same binary game/app could support keyboard on Pandora and display a virtual keyboard on the GP2X/Wiz. It would also mean than my binaries could work on future ARM based handhelds/UMPC's as long as they support the features I need.

I would also be keen to write a Win/Linux clone of the final API to help with debugging/testing and rolling out PC versions without much effort. Obviously SDL already offers most of this but the minimal lib is just simpler and fits the way that handhelds work nicely. Plus it might be easier to maintain multiple ports (gp2x-F1/200, Pandora, Wiz, future fantasy console) and binary compatibility with a smaller, dedicated library.

 

[GernotFrisch]

I use such a HW lib, with #ifdefs for each platform. If there's something I can do with certain hardware, I do. If not, I use the default unix/windows commands for that task.
If you need milisecond resolution, gettimeofday requires one multiplication and one division, e.g., which costs on a GP2X.

But I think that's the idea behind SDL, too.