pouët.net

Or, generally: Decide what you want to do - it's either multiplatform or actually getting stuff done. Seriously, just go for one platform/API first - when you're finally experienced enough it's way easier to refactor the stuff to run somewhere else.

The time you spent fooling around just to get all your non-native libraries to compile is enough to open a new project in VS, open a window, initialize DirectX and get a spinning cube on screen. Guess what's more rewarding at the end of the day :)

Multiplatform doesn't take much extra effort if it's a mindset instead of an afterthought. Just go with portable libraries instead of platform-specific ones in the first place and avoid the most glaring mistakes.

If I go non-multiplatform ie. Wintel, I'll probably go for SlimDX as C# seems like a pretty decent language to develop on after I've been spoiled in Java/Actionscript land where IDEs such as IntelliJ IDEA write half of your code automatically and structure is well defined and easy to structure. On otherhand SlimDX seems more flexible than XNA or MonoGame route.

What don't you like from JavaScript / WebGL?

JavaScript = typeless = crap

Marq: Wrong. Multiplatform doesn't take much effort _if you exactly know what you're doing_ or if the problem at hand doesn't use much of the underlying platform anyway. Starting graphics programming is the complete opposite. Getting demos to run on more than one platform is a big lot more effort than "just use SDL". See all the linux demos that don't even run on the machine next to the coder's one. Trust me, I've been a party organizer long enough, and in the last 5 years on several parties I've seen ONE Linux demo that actually ran correctly on the compo machine. That's a bit less than the quota you get under Windows, which is basically "all of them".

And you don't seriously want to suggest people should use the gcc toolchain (or a derivative) under a non-GNU based OS, do you?


Anyway. C# / SlimDX (or SharpDX if you're into performance and can live without some helpers) seems to be a good solution nowadays. Most stuff is going on in the GPU anyway. :)

It's not typeless. It's weakly typed, which is the real crap.
http://www.youtube.com/watch?v=_yZHbh396rc(The talk is wrong in one aspect: [] + {} is not Object, its a String with content "[object Object]")

jalava: but... but wait! https://github.com/adobe/glsl2agal

@Joghurt : very nice and funny video

Amiga?

AAAAMIGAAAAA!!!11!!!

there. fixed that for you. ;)

kb_: When did gl+sdl or a framebuffer become non-graphics programming? Trust me, I've ported tens of demos to some 20 platforms, and it's not a big deal _if_ the code is even somewhat structured and not polluted with platform/compiler-specific calls everywhere. Linux or Windows demos running on some (probably Nvidia-based) compo machine doesn't have much to do with cross-platform portability, or does it?

GCC cross-compiling is what a lot of people do for PSP, GBA SP, GP2x, Raspberry Pi etc. I don't love the slow, bloated and complex mammoth which it is, but in many cases it's the only option and gets the job done. And anyway, if the code is clean (which demo code usually isn't) the jump between Makefiles and project files is the smallest thing to worry about.

Isn't that exactly what KB just said?

Marq: Demos running on a compo machine has lots to do with cross platform compatibility because if you go the "portable" (haha) gl+sdl route, every single Linux distribution, every graphics card vendor and every third driver revision (regardless of the OS) suddenly becomes a platform on its own. And the more you make use of GL, the worse it gets.

UNLESS of course you're experienced in all this and know what platform does what and which code paths of OpenGL are currently the good ones, and whatnot. You do, so do I (I also ported countless games and demos from one platform to the next), and you're right: It's not even that hard, and I repeat myself, _if you know what you're doing_.

But I was giving an advice to someone trying to get into all of this stuff. And my point stands: Thinking about cross platform compatibility from the very start is distracting and nothing more. It won't work anyway, and all you get is a lot more hassle. Just use the stuff that's native, well working and well documented, and care about porting or abstracting later.

There are still plenty of decisions that will help or hinder the portability in the long run, and that stuff you can get right from the beginning, instead of learning everything the hard way. Digging deep into some platform-specific API will probably just lead you to sticking to it. I agree that "knowing what you're doing" is useful :)

I'm on the Amiga side, naturally :)
You may have to rely on your own 3D engine but you won't have a big hassle with timing and sound.

Apart from "let's not litter the whole code with API calls", how? Even determining where to draw the line for your abstraction layer takes years of experience. I'll stay with that one sentence I read somewhere around the design patterns thread recently: "Don't think about code reuse, think about code USE". Especially if you're doing something you haven't done before.

Need to get the low-level stuff, too, such as byte order, variable sizes, alignment rules, stack size, type conversion side effects etc.

That's all fine and dandy but still a distraction from what you actually want to do, unless you keep it in the back of your head anyway, which, surprise, comes with experience.

Just thinking out loud here, but what about QT?


QML/QTQuick for easy declarations and scripting, Mobility framework for cross platform support, QTCreator is a quite dandy IDE and it has plethora of various modules for animation and multimedia.

And off course their new QT3D module which is made with QTQuick in mind.(though beta)

Now, keep in mind that I've never touched QML, QT's alleged cross platform prowess nor scratched a 1/10 of QT...so...bash away.

Hurry up before Oracle gets a hand on it.

in the first post it seems Jalava is against unity. What are the reasons for this ? Also what is the opinion of demosceners about this engine ?

It seems unity is used a lot in games dev prototyping or by people that do game development as a hobby. Never heard about it in demoscene.

I <3 Qt use it every day, but it also only solves the portability issue to SOME extent.
If you're doing 3D with C++ and OpenGL it can give you a render window / context / fbo (not much more) on Win/Linux/Mac (and Meego), which not thaat hard to do anyway. I personally don't like QML much though in combination with QtScript (which tada is JavaScript again) it is pretty powerful. QtCreator is a nice IDE, but not en par with Eclipse or VS.
All in all I think for a demo Qt might be a bit overkill... Intros are not really doable with Qt, the libs/dlls are quite big.

I might be wrong here but last time I checked only way to code custom code with Unity and not just point&click games together was to purchase the pro version?

Also, after reading tutorial about what it looks like to create procedural mesh components on C# with Unity, I'm even more put of.

What I'm looking to do is operator based demo graph (similar what WKZ and many others are doing) with simple way to create your own components, but after operators are compiled in, it would allow to do your demos with simple scripting only by connecting operator inputs and output together in code or with GUI tooling. This should allow me to define the operator functionality and metadata in such way that same asset format and demoscript would be multiplatform but each player would contain custom code to extent.

Bit unsure still where to draw the line on script / native even. HaXe with OpenGL bindings perhaps, as I'm semi familiar with OpenGL already and HaXe is kinda like ActionScript but compiles to native executable (or NekoVM) also. Also demoscript itself (static graphs ar boring, graphs with hooks to script snippets should do what I want) should optimally be on the fly codeable without compile so throwing in script intepreter in there too.

Now I'm just brainstorming, perhaps it's time to go hunting some scaffolding.

And how about http://dartlang.org?

I'm now evaluating Urho3D (From the maker of GoatTracker), which seems almost exactly about what I am looking for, complete multiplayer 3d engine with scripting that allows me to concentrate on making demos and demotools and not worry about lower level 3d engine programming. Of course different platforms probably require their own shaders, custom render pipelines etc, but that was expected anyway.

Now I just need to see what I can make of it. Anyone tried to do stuff with it?