Development Poll About My New Crosslibrary Sdk (formerly Known As Hpl)

[rlyeh]

I'm currently coding a new multiplatform C++ SDK aimed to both prototype and cross-compile small applications (games, emulators, and homebrew stuff in my case).

The current SDK implementation (6th rewrite) is elegant, portable, maintenable, minimalistic and damn easy to read and follow. It should be as fast as pure C if everything stays the same for a few months.

It has been tested so far on Win32 and results are promising. A bunch of supported platforms are expected in the first release, as porting this framework is a trivial task as long as your compiler supports advanced C++.

However, in my search for my personal holygrail, I might have focused my attention on parts that should be probably better designed, or designed in a different way. I'm pretty sure my current implementation lacks many things you should use.

All those options on poll #1 are already implemented in a more or less advanced state.
This poll #1 will help me balancing where I should specifically focus my efforts on from now.

I will create more polls in this thread as long as we get enough questions/suggestions worth for a poll.

Thanks for spending your time in this thread

---

For the curious people out there, here is a very basic wip sample that is using the current wip SDK.
Please notice that the actual API may (and will) change.
Visit the link

 

[Exophase]

I can't limit my answers to one, but these ones:

"Support for displaying your frames in multiple buffers when possible (aka, N-buffering)"
"Support for high precission timers despite the platform tick resolution"

But this is a very major issue:

"Support for language bindings (currently there is only C++ supported)"

A good number (maybe even most) of us are using C and will not use a library that requires C++ or anything equivalent. I really don't see any reason why C++ is necessary to provide most of these things. If you feel that way maybe you should split it into a C part and a C++ part. Pretty much anything can easily use C, C++ is a totally different case.

 

[rlyeh]

@Exophase
Thanks for the reply. Language bindings aren't my strong point. I guess I won't be able to bind to any other language lower than C++, since it's using meta-programming (templates) and OOP. Maybe we could bind to C#, D, or something else. Please any help here is more than welcomed.

I know the poll is too much ambitious for a single answer.
Is there an option to allow multiple option validation in these boards?

 

[paeryn]

I went for other language bindings (due to a preference for C), but n-buffering too.

Also multiple thread support, or at least thread-safeness.

 

[multiplex]

@Exophase
Thanks for the reply. Language bindings aren't my strong point. I guess I won't be able to bind to any other language lower than C++, since it's using meta-programming (templates) and OOP. Maybe we could bind to C#, D, or something else. Please any help here is more than welcomed.

As far as I've heard, interfacing directly with C++ compiled code is pretty hellish, so few (none?) non-C++ based languages try to. That means most C++ library bindings are done by exporting a C interface in some form as a middle man. You certainly won't be able to interface with C++'s rather unique template system from any other language. Maybe there's solutions out there based on dynamically creating interface code at buildtime or some other such kludge.

I'm not really the target market for such an SDK, but aren't some of the things listed, like threads, already dead simple with e.g. SDL? Best to start with the areas that you feel you can improve the most, I'd say.

 

[rlyeh]

@Multiplex
Thanks for the info.
I rather like OpenMP than any other threading solutions, but I guess it's a relatively recent implementation, and might confuse people.

Back to the bindings, I'll probably be using SWIG when the SDK is almost done to bind to a bunch of languages/scripts. Hope that helps.

It's now supporting C++ to C binding too

 

[Dunny]

I've tried coding in C/C++ before now and I hate it with a passion. My platform of choice is Pascal (Delphi on Win32), so being able to use it with a pascal header file would be most cool. Accessing DLL files in windows is simplicity itself in Delphi, I'd like to be able to do that with fpc if possible.

Of course, if fpc can't do that, then feel free to ignore me

D.

 

[AireTamStorm]

I have to agree with language bindings. There are many promising things coming out of the Python and Ruby communities nowadays, despite not being very efficient use of resources.

Network libraries can be written by anyone, hell, I'm writing one myself right now

 

[skeezix]

hey rlyeh

(Nothing like a new machine coming out to bring all us GP-old-timers back out eh?

Don't make me rant but to be pedantic .. OOP is not limited to C++; C is just as OOPy, just C++ attempts to make it more language driven than library driven. (Consider the "FILE" stuff in C; FILE is an abstract object, with an accessor 'class' in the stdio functions. Many people have created a struct to holde func ptrs to the FILE functions even, to collect them into a class (remembering that a C++ class is really just a struct.)

Anyway, thats just me being a wanker.

Things like 'automatic scaling' are pretty silly IMHO; they can be options to the renderer or in the init, but are entirely unnecessary really; the dev can stretch if he wants (not hard at all!)

A magic filesystem is probably out of scope for a cross platform toolkit; STAY TO THE METAL MAN. You're not trying to provide a full stakc, or you'll never ship anything. Most of us have already gotten things like this anyway. You do have something, I've seen it.. so ship it as an add-on or side project, to read files form a filesystem or a zipfile or a pak file.. its trivial to do it anyway (even windows supports / now in addition to \, so why worry?

Timers -- need!

Unified input -- within reason, handy.

Unified basic blitting -- needed, but don't over do it

Don't bother with 3d yet, add it later or as an add-on extension.

Remember, devs aren't stupid; all they need is a very basic package, and it'll get used. Remember minimal lib? Very short, to the point, providing the basics, and used by everyone. Further, written in a short time.

If you aim for the world, you're going to under deliver, and late

Again, your readabiloity is top notch.. very nice.

If you want to make your lib all C++, thats fine, just expect the first thing we'll all do is make C wrappers for it

Can you at least put in top/bottom of your headers..

#ifdef __cplusplus
extern "C" {
#endif

..

#ifdef __cplusplus
} /* extern C */
#endif

To save Exo from doing it?

jeff

Whose working on 'minimal' for pandora anyway? theres at least3 people I think

 

[rlyeh]

@Skeezix

Thanks for the long reply.

I know you can code "OOP" in C but it is a little more complicated than C++, and still you cant use templates or operator overloading, which I use in favor of old macros.

@Skeezix "Things like 'automatic scaling' are pretty silly IMHO;"

I disagree with this.
How would you port a 640x480 app to a 320x240 device? I'd say by rescaling, ok (*).
But what about a 256x192 app to a 320x240 device? Centering? Enlarging?
And a 320x384 app to a 320x240 device? Cropping (*)? Squeezing (*)?

There are plenty of options you could choose from if working with VRAM directly (instead of surfaces) and don't wanna piss off the framebuffer memory directly. Ie, (*) will hang up the 320x240 device.

@Skeezix "A magic filesystem is probably out of scope for a cross platform toolkit;"

I don't think really stdio.h is that portable (see GP32 case). Although windows may accept now the / slash, the GP2X apps will still need the "/mnt/sd/" and its own path, and many other systems will. There are ROM embedded systems that do not cope with the fopen() stuff. There are systems that stream files from network. Other systems got files embedded files into the binary as resources. etc.

The intention of my lib is to create a final source code for all platforms with no source code alteration, so after having ported a few apps, I feel the need to rewrite any aspects that I know make a cross-compilation a failure, like the filesystem.

@Skeezix "Don't bother with 3d yet, add it later or as an add-on extension."

Didn't plan to add it (Thankful god :S)

@Skeezix "devs aren't stupid; all they need is a very basic package, and it'll get used."

Of course. I'll need it too! I'm waiting for someone to write one before me.
My library is beyond the minimal libraries concept, since it is a layer above over them.

@Skeezix "If you want to make your lib all C++, thats fine, just expect the first thing we'll all do is make C wrappers for it "

I was planning to let SWIG to do the automatized-dirty work.
But if there are brave volunteers out there eagering to suffer and to blood, then it will be great ! ;-)

@Skeezix "Can you at least put in top/bottom of your headers.."

That's done for those cases when you use a C library in a C++ context. Not the inverse.
Tell me if I'm wrong!


All your comments were greatly appreciated!

 

[synkro]

This is one heavy poll, so I voted for eye-candy beause effects are harder to code then blitting and moving some bitmap. I also don't know exactly what feature yours SDK is going to have.

Using C-style coding in a C++ environment is no real problem and C-lovers will easily adapt. As rleyh is going to use templates, just wrapping the calls to C won't work I guess. Bindings to other languages like Riby would be awesome, but only a really small minority would use it anyway. Make it stable in C++ and then have a look.

Now that yoo made em curious I'll ask some questions of course, ya know me

QUOTE
It should be as fast as pure C if everything stays the same for a few months.

What do you mean by "staying the same for a few months"? How do you prevent virtual function calls (e.g. aggregating) and code bloat from templates?

Do you provide a portable float/fixed type?
Is Linux also a supported platform?

 

[rlyeh]

@synkro

What do you mean by "staying the same for a few months"?
"if i dont mess with the sources too much..."

How do you prevent virtual function calls (e.g. aggregating) and code bloat from templates?
By using lots of constants, specially on ifs()/switchs()/fors(), and let the compiler do all the dirty work.

Do you provide a portable float/fixed type?
Yes I do. I still have to decide yet I should support user-defined decimal bits or let the port choose the best approach.

Is Linux also a supported platform?
Considering the amount of Linux source code out there I guess Linux will probably be the fastest port to be done once the Win32 one is fully finished.

 

[skeezix]

Rleyh my man,

My comments are in summary .. aim smaller, and designer larger, I guess. ie: A lot of big toolkits are out there, and trhey take a lot of work from a lot of people, and you end up maintaining this toolkit rather tangetting to where you want to go, which is the app that uses it.

So prioritize what you think is needed, and build those things in, and release; add more later, and release again. When I say a generic xplatform filesystem is not needed per se,I mean to say that we all have our own little systems already and for new people, its trivial enough to do. (ie: zipfile, or worst, a zipfile that is then translated into a C array and compiled right in. Trivial to do, and always works, when your compiler cna handle the size of the file.)

Instead, focus on the 'minimal lib' level first (getting framebuffer working 1:1, timers, inputs), then another layher on top for the next set of useful things.. some stretch/zoom blitters and so on. Devs can fill in what is missing as long as they have the basics.

ie: Auto-scaling can be nice sure, but its 'optional' IMHO; you can always give back the screen dimensions and let the dev call a vblit function as they see fit. ie: center, zoom, stretch, whatever.

Design in for 'as best as you cna see the future', but then code small and work your way up

Maybe we're saying the same thing. I don't get to sleep at night, so I ramble (and my toolkit is a total mess, so don't listen to me.

jeff

 

[rlyeh]

'Lo

The poll seems quite inactive lately so I guess we could say poll closed from now.

It's interesting that people seems to like language bindings a lot (or seems to hate C++ at all

Thanks for everyone involved.

SDK is going so far straight and non-stop, which is pretty good.

Next poll is to discuss about the unified HID system which is implemented already.
It might be worthy to see different point of views about this yet-to-universally-implement old topic.

 

[Klepto]

I'm not a C++ dev so I didn't vote, but if I did it would be for other language bindings. I'm just posting to say that if you produce C bindings (it looks like you might) then it should be pretty trivial for the likes of me to write a wrapper for our language of choice.