SDL 2 / Visual Studio 2012 - Windows Store Certification

SDL 2 / Visual Studio 2012 - Windows Store Certification…

Hi,

The new Windows Store in Windows 8 is the future of Windows application distribution (good or bad).
(old days of creating an EXE Windows installer are dying quickly because of Win 8)

I used “GameMaker: Studio - Professional” to make a Tetris game recently
and released it to the Windows Store but it did not succeed and failed terribly (~150 downloads in two weeks).

Despite the above failure, I wish to port my very successful “TetriCrisis 4 110% A.I.” to Windows Store.
I wish to use SDL2, SDL2_Image, SDL2_Mixer, SDL2_TTF in Microsoft Visual Studio Express 2012.

Before I spend the time to port TC4 from SDL 1.2 to SDL2 to be published in the Windows Store using MSVSexpress12
I just need to know if this is even possible.

Has anyone here made a game with SDL 2 and built a Windows Store app using Microsoft Visual Studio Express 2012?
Thanks!------------------------
JeZ+Lee
JessePalser <AT> Gmail <DOT> com
16BitSoft®
Video Game Design Studio
www.16BitSoft.com

I wouldn’t be so sure about that.? Have you looked at the numbers lately?? Only thing dying is Microsoft’s attempt at turning an open, thriving ecosystem into a “walled garden.”? Windows 8 is a joke, and the only people not laughing are in Redmond.________________________________
From: JeZ-l-Lee
To: sdl at lists.libsdl.org
Sent: Saturday, August 10, 2013 4:33 PM
Subject: [SDL] SDL 2 / Visual Studio 2012 - Windows Store Certification…

The new Windows Store in Windows 8 is the future of Windows application distribution (good or bad).
(old days of creating an EXE Windows installer are dying quickly because of Win 8)

JeZ-l-Lee , you are likely going to run into some problems. I was working
on a Windows 8 application for an old job, and had many problems bringing
standard C libraries into that programming environment. For instance, as a
Windows App, you cannot use raw sockets, you need to use the Windows 8
asynchronous socket interface. File IO was the same deal, that you
couldn’t just use fopen, you would have to use the special Windows 8 API
for asynchronous IO.

The main issue you’ll have is that the Windows 8 Application API is written
in C++ (using the new C++11 standard plus some Microsoft custom
extensions), so SDL, being C98 (that’s still the case, right?), will not be
able to directly use the C++ classes the Windows API exposes.

I don’t know if any of the SDL devs have thought about porting the SDL API
so the Windows 8 App API could be used, but I think it’s unlikely since C98
is the bare-minimum standard across the main compilers, so it wouldn’t make
sense to bump that up to C++11.

This is only from my experience of the Windows 8 App API, and that was
about 6 months ago, so perhaps some of that has changed, but as far as I’m
concerned, SDL and the Windows 8 Store App API are not compatible.On Sat, Aug 10, 2013 at 7:50 PM, Mason Wheeler wrote:

I wouldn’t be so sure about that. Have you looked at the numbers lately?
Only thing dying is Microsoft’s attempt at turning an open, thriving
ecosystem into a “walled garden.” Windows 8 is a joke, and the only people
not laughing are in Redmond.

As much as I agree with you, if anyone wants to continue this discussion
about merits and problems with Windows 8, it should probably happen outside
of the list, since it’s mostly opinion.

The main issue you’ll have is that the Windows 8 Application API is written in C++ (using the new C++11 standard plus some Microsoft custom extensions), so SDL, being C98 (that’s still the case, right?), will not be able to directly use the C++ classes the Windows API exposes.

So you would need a C binding layer. Is that something new for SDL?
No, SDL already has binding layers for ObjC, Android-ish Java stuff, etc.

I don’t know if any of the SDL devs have thought about porting the SDL API so the Windows 8 App API could be used, but I think it’s unlikely since C98 is the bare-minimum standard across the main compilers, so it wouldn’t make sense to bump that up to C++11.

Actually it does. The next version of SDL should be C++ because it’s a superior
programming environment. A lot more stuff would work correctly first time
and a lot more stuff could be made to work at all. The majority of programmers
would then have a decent API to use and C programmers would be able to
use a C binding. At least part of the library would still have to have
extern “C” functions or run time linkage wouldn’t work. The only real
technical obstacles would be with enums (since they’re first class
data types in C++ and don’t have auto-conversion with other integers).On 11/08/2013, at 10:08 AM, Alex Barry wrote:


john skaller
@john_skaller
http://felix-lang.org

The main issue you’ll have is that the Windows 8 Application API is
written in C++ (using the new C++11 standard plus some Microsoft custom
extensions), so SDL, being C98 (that’s still the case, right?), will not be
able to directly use the C++ classes the Windows API exposes.

So you would need a C binding layer. Is that something new for SDL?
No, SDL already has binding layers for ObjC, Android-ish Java stuff, etc.

Well, yes and no. The binding layer is for another language to use SDL,
but in this case, we are asking SDL to use the language. C98 does not
understand what a C++ class is, plain and simple.

I don’t know if any of the SDL devs have thought about porting the SDL
API so the Windows 8 App API could be used, but I think it’s unlikely since
C98 is the bare-minimum standard across the main compilers, so it wouldn’t
make sense to bump that up to C++11.

Actually it does. The next version of SDL should be C++ because it’s a
superior
programming environment. A lot more stuff would work correctly first time
and a lot more stuff could be made to work at all. The majority of
programmers
would then have a decent API to use and C programmers would be able to
use a C binding. At least part of the library would still have to have
extern “C” functions or run time linkage wouldn’t work. The only real
technical obstacles would be with enums (since they’re first class
data types in C++ and don’t have auto-conversion with other integers).

I don’t disagree that C++ has many advantages, but that’s something for the
SDL devs to decide. Right now, we can guarantee that any modern C compiler
will support most of the C98 standard. If SDL decided to move to C++, then
that would have to be re-evaluated. The difference between C and C++
mostly boils down to programming styles - each have their advantage, and
each have their own styles of how APIs are built. Namespaces and Classes
in C++ can be great tools for organization in C++, but organization by
files and function/structure prefixes work just as well in C.On Sat, Aug 10, 2013 at 10:41 PM, john skaller < skaller at users.sourceforge.net> wrote:

On 11/08/2013, at 10:08 AM, Alex Barry wrote:

JeZ-l-Lee wrote:

Before I spend the time to port TC4 from SDL 1.2 to SDL2 to be published in the Windows Store using MSVSexpress12
I just need to know if this is even possible.

Has anyone here made a game with SDL 2 and built a Windows Store app using Microsoft Visual Studio Express 2012?
Thanks!

It’s possible, although it’s not entirely straight-forward.

I’ve done a fairly rough port of SDL2 to WinRT. At least one developer has released a pair of apps using a slightly modified version of it. More info on the port is at https://bitbucket.org/DavidLudwig/sdl/wiki/Home

A few notes:

  • the port is -very- rough ATM. You may end up having to make some modifications yourself. Bugs do exist.
  • a few-month-old version of SDL2 is currently getting used. I have no specific time-frame on when I’ll be able to update it, but am hoping to get to this late-summer / early-fall (when I’m hoping to have a bit more free time, no guarantees though).
  • WinRT-specific documentation is not yet available.

You’re welcome to use it, if you like, or just use it as a reference.

Cheers,
– David L.

2013/8/10, john skaller :

Actually it does. The next version of SDL should be C++ because it’s a
superior
programming environment. A lot more stuff would work correctly first time
and a lot more stuff could be made to work at all. The majority of
programmers
would then have a decent API to use and C programmers would be able to
use a C binding. At least part of the library would still have to have
extern “C” functions or run time linkage wouldn’t work. The only real
technical obstacles would be with enums (since they’re first class
data types in C++ and don’t have auto-conversion with other integers).

I love how you constantly praise C++ as being superior to C and
completely ignore that now there are major languages that are much
better than C++ at the job. C++ at this point is such a horrible mess
that doesn’t know whether it wants to be low level like C or high
level like newer languages, and ends up screwing up horribly at both
jobs for that reason.

Seriously, stop that, it’s getting annoying.

The main issue you’ll have is that the Windows 8 Application API is written in C++ (using the new C++11 standard plus some Microsoft custom extensions), so SDL, being C98 (that’s still the case, right?), will not be able to directly use the C++ classes the Windows API exposes.

So you would need a C binding layer. Is that something new for SDL?
No, SDL already has binding layers for ObjC, Android-ish Java stuff, etc.

Well, yes and no. The binding layer is for another language to use SDL, but in this case, we are asking SDL to use the language.

You misunderstand my intent. Right now, SDL is written in C and it interfaces
with Obj-C on OSX because this is the only way to do stuff on OSX. There is
Obj-C code in SDL. On Android I’m told there is a heap of Java’ish stuff
to set up the environment for an app (I don’t know Android though so I
could be wrong).

So I am actually talking about C code in SDL already having to call
other languages (not about calling SDL from other languages).

C98 does not understand what a C++ class is, plain and simple.

But C bindings can be created for C++ and people do it all the time.

I don’t disagree that C++ has many advantages, but that’s something for the SDL devs to decide. Right now, we can guarantee that any modern C compiler will support most of the C98 standard.

Except Microsoft doesn’t supply one on Windows 7 it seems. Oh, and Microsoft on Windows 8 it seems.
In other words, the biggest desktop OS supplier in the world doesn’t support C.

If SDL decided to move to C++, then that would have to be re-evaluated. The difference between C and C++ mostly boils down to programming styles - each have their advantage, and each have their own styles of how APIs are built. Namespaces and Classes in C++ can be great tools for organization in C++, but organization by files and function/structure prefixes work just as well in C.

I have seen some horrible C++ code. Its true all C is equally horrible,
whereas in C++ there are a lot of different ways to write ugly code :)On 11/08/2013, at 12:56 PM, Alex Barry wrote:

On Sat, Aug 10, 2013 at 10:41 PM, john skaller <@john_skaller> wrote:
On 11/08/2013, at 10:08 AM, Alex Barry wrote:


john skaller
@john_skaller
http://felix-lang.org

Amen! C++ is only “a superior language” if you’re comparing it to something like INTERCAL.? It may not be the worst language ever created, but it absolutely is the worst to ever be taken seriously, and I for one hope SDL never so much as touches it with a 10-foot pole.

Mason.________________________________
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Sent: Saturday, August 10, 2013 8:17 PM
Subject: Re: [SDL] SDL 2 / Visual Studio 2012 - Windows Store Certification…

I love how you constantly praise C++ as being superior to C and
completely ignore that now there are major languages that are much
better than C++ at the job. C++ at this point is such a horrible mess
that doesn’t know whether it wants to be low level like C or high
level like newer languages, and ends up screwing up horribly at both
jobs for that reason.

Seriously, stop that, it’s getting annoying.

C98 does not understand what a C++ class is, plain and simple.

But C bindings can be created for C++ and people do it all the time.

And it seem the OP has in fact done this too, here’s a quote from the website:

“”"
? threads. Significant chunks of Win32’s threading APIs are not available in WinRT. A new, SDL threading backend was built using C++11’s threading APIs (std::thread, std::mutex, std::condition_variable, etc.). C programs should be able to access these (via SDL). Support for thread priorities is not, however, currently available, but may be in the future.
"""On 11/08/2013, at 1:31 PM, john skaller wrote:


john skaller
@john_skaller
http://felix-lang.org

Actually it does. The next version of SDL should be C++ because it’s a superior
programming environment.

I don’t think this is going to happen.

That being said, we have had C++ code in SDL before (for example, the
system API of BeOS was C++, so we needed it to create windows, etc), so
the platform-specific pieces can be whatever language, just like we have
some Objective-C code in SDL for Mac OS X and iOS.

–ryan.

Actually it does. The next version of SDL should be C++ because it’s a superior
programming environment.

I don’t think this is going to happen.

Neither do I, but I had to say it :slight_smile:

That being said, we have had C++ code in SDL before (for example, the system API of BeOS was C++, so we needed it to create windows, etc), so the platform-specific pieces can be whatever language, just like we have some Objective-C code in SDL for Mac OS X and iOS.

The build system must be a nightmare. Have to say it works fine on OSX!On 12/08/2013, at 2:50 PM, Ryan C. Gordon wrote:


john skaller
@john_skaller
http://felix-lang.org

Hi,

No Windows Store support is disappointing to say the least.
Guess I have to use “GameMaker: Studio - Professional” again to release a Windows Store game.
Thanks!------------------------
JeZ+Lee
JessePalser <AT> Gmail <DOT> com
16BitSoft®
Video Game Design Studio
www.16BitSoft.com

Hello,

To answer your first question. A few month ago, I did publish ten
small games on the Windows Store, using SDL2, SDL2_Image, SDL2_Mixer
and SDL2_TTF
(and their depencies : libPNG libjpeg, zlib, vorbis).
The games were already working on IOS and Android, and now are
available for Windows8 and WinRT.

I use the excellent porting done by David Ludwig
(https://bitbucket.org/DavidLudwig/sdl/wiki/Home)
David says it is not finished at the moment, but I believe it is
already in a pretty good shape !
Some API have not yet been implemented (e.g. SDL touch API).
But all games are running correctly with no major problem.

I have two small local modifications : an early call to a resize
function, for an orientation issue, and a side menu for a link to a
webpage.
(modifcations that I already shared with David, and that I can re-send
if needed)

If I remember correctly here the few issues I got when submitting to
Windows Store :

  • no Exit button (like IOS)
  • no publication in the following countries without a rating
    certificate : Taiwan, Brazil, South Korea, South Africa.
  • need to include in you app a privacy/policy statement (e.g. link to
    a webpage).
  • no call to OututDebugPrint function allowed (one was done in png_debug.c)

Best regards,

SylvainOn Mon, Aug 12, 2013 at 9:08 AM, JeZ-l-Lee wrote:

Hi,

No Windows Store support is disappointing to say the least.
Guess I have to use “GameMaker: Studio - Professional” again to release a
Windows Store game.
Thanks!


JeZ+Lee
JessePalser Gmail com
16BitSoft®
Video Game Design Studio
www.16BitSoft.com


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/8/12 Ryan C. Gordon

Actually it does. The next version of SDL should be C++ because it’s a

superior
programming environment.

I don’t think this is going to happen.

That being said, we have had C++ code in SDL before (for example, the
system API of BeOS was C++, so we needed it to create windows, etc), so the
platform-specific pieces can be whatever language, just like we have some
Objective-C code in SDL for Mac OS X and iOS.

–ryan.

The Android code was until recently C++, it was deliberately changed to C
starting here: http://hg.libsdl.org/SDL/rev/b27825bb5879

I think there’s a good deal of merit in keeping SDL grounded in a
technological lowest common denominator, whatever platform the future will
throw at us, chances are there’s going to be a C compiler for it :)–
Gabriel.