Flare 1.0 and SDL 2.0

[clintbellanger]

SDL 2.0 is now stable.

Do we want Flare 1.0 (or the 1.x series which will try to be a stable long-term branch) to use SDL 2.0?

SDL 2.0 support should be fine on modern OSes or devices, but I'm wondering if we'd be cutting off too many old systems by making the switch. How can we find out the status of where SDL 2.0 has been ported?

[stefanbeller]

The development ceased a little lately, because there were no interesting topics. Also the number of bug reports is very low, so I consider the current state of the engine in a real good shape.

According to http://flarerpg.org/todo/ the 0.20 goal (Full menu support for systems without mouse/pointer) is already met, but the 0.19 goal (floating point movement) is lacking because I lost motivation mid through. While the playing fully mouseless enhances the usability to more devices the floating point movement is not really pushing the engine forwards for a broader spectrum of users. So I'd be even in the mood to call the current state stable enough for an early release candidate 1.0-rc0. So I would not open another large rewriting task for the 1.0 release.

On the other hand, the it takes some time to get these really nice art, you're aiming for. So there would be plenty of time to rewrite and it would be stable by the time most of the art is there.

So here is another spontaneous idea, which collides all the version numbering plans as of now:

• Use the current content/art/engine to release the Flare 1.0
• Rewrite for SDL2.0 and get the Wandercall art together and release that as Flare 2.0 (It will take some time, I promise ;) )
• This idea obviously messes with a specific game again, but we wanted to separate the engine from the actual games, to have more games available. On the other hand I could imagine that @makrohn would like to rely on engine 1.0 for polymorphable and concordia instead of 0.18 for psychological reasons. And as this idea is actually about naming only, I see no reason against an early 1.0 release.

[dorkster]

Some questions:

• Do we plan to use specific SDL 2.0 features? (e.g. SDL_Texture instead of SDL_Surface for accelerated gfx)
• Are the major Linux distros going to drop 1.2 now that 2.0 is stable? If so, I think it would be vital to make the switch, since I'm assuming a majority of Flare's userbase uses Linux (do we have stats on OS usage?)
• Would it be viable to allow both 2.0 and 1.2 with #ifdefs and such? (probably a bad idea from a support perspective)

[clintbellanger]

I'd prefer to switch over to SDL_Texture. I'd rather not use ifdefs (for the obvious support reasons).

I'm okay with the idea of Flare 1.x sticking with SDL 1.x, if SDL 1.x will be around for a while. I imagine it will be, too many existing games require it and won't be ported.

I'm also okay with getting the floating point move code done and bumping Flare to 1.0-rc0. I think at that point we could even create the Flare 2.0 repo with porting to SDL 2 as the first main mission.

[stefanbeller]

@dorkster There is http://sourceforge.net/projects/flare-game/files/stats/os which details the downloads for different platforms. (Also interesting and shown are countries and timeline.) There are 150 weekly linux dowloads (46 % of the users) But specially Linux users tend to use the package manager, where I'd guess there are no statistics available, except for http://popcon.debian.org/ (which only reports package usage of debian users, who opted in for the popularity contest, a similar thing exists for ubuntu as well. I am unsure about other distros. For debian there are 144 users who use this package regularly, but only 31 who installed this package, so take these numbers with a grain of salt.)

[manuelafm]

(Only about statistics in Debian: http://qa.debian.org/popcon.php?package=flare , click "Help" text near the top-left for explanation)

Stefan, I think that you are reading the statistics incorrectly. It's ~194 Installed (0.13% of all reports, including servers and so on which obviously will not have games installed), of which 31 "Vote [for it]" (which actually means that it was used lately, if your filesystem has "last access time" info for the binaries, which some systems do no), and Old (installed but no indication that was accessed lately), Recent (installed/upgraded recently) and No files (the package was "removed" but not "purged", which in .deb world parlance means that the config files are preserved -- mostly important for servers/daemons only, but it's basically the same: actually not installed).

You can compare it to other games ("popcon" column, click on column title to sort by it, and click the link of each number for the detailed graphs and stats): http://qa.debian.org/developer.php?login=pkg-games-devel@lists.alioth.debian.org

The ones with most popularity are tuxracer, freeciv and supertux cart, 10 times more than Flare, but they are well known for very long time. The popular Wesnoth is ~7/8 times more popular than flare, ScummVM and the most popular Quake clones only ~6 times.

Hope that helps to interpret the data, although since there's unclear how many users enable this "popularity contest", there's no way to tell the real number of installation: probably 10 times more at least, but who knows.

And SDL 1.2 will not be removed any time soon, no, count on it for 2/3 years at the very least.

[rinnert]

I am working towards SDL2 support in my fork. I created a branch sdl2_support in which I intend to remove all OpenGL stuff and replace it by the SDL2 equivalent. That'll be fairly easy and quick as the semantics are identical. I won't do it tonight, though. :)

There are some issues I'd like to put forward for you to discuss:

1. Any cmake expert around? Right now I have hacked something for SDL2 that's clearly not portable. Any help is very much appreciated.
2. The plan is that my sdl2_support branch will support both, SDL 1.2 and SDL 2.0. What is used will be decided by the environment when you do cmake. I had some exchange with Igor. He thinks having separate branches for 1.2 and 2.0 would be better. I think it's better to have it all in one branch (don't worry about #ifdef pollution, it's fairly minimal, as you can tell from my current OpenGL implementation). The reason I favour one branch is that I think it simplifies maintenance. Igor has the same reason for the opposite. So, well, your input on this is welcome.
3. Animated tiles. There is a code path in the MapRenderer dealing with ANIMATED_TILES being false. This is impossible to support efficiently with SDL2 textures (as well as OpenGL, not surprisingly). This means SDL2 will require ANIMATED_TILES. Any thoughts on that?

[igorko]

Hello @rinnert. I'm not saying having SDL and SDL2 support in one tree is bad, I'm just saying this will need huge rewrite and a lot of ifdefs (because I have already did this in my branch). If you see, that you can make migrating without a lot of pain, feel free to do this, and then community will decide what to do next.

@dorkster said: "Would it be viable to allow both 2.0 and 1.2 with #ifdefs and such? (probably a bad idea from a support perspective)"

[eezstreet]

I picked up Flare again and I was also interested in SDL 2.0 support for the game. I use SDL for another project and it is pretty nice in comparison to SDL 1.2, especially since it doesn't have the input gobbling issue when trying to debug.

[igorko]

I was able to build Flare with SDL2 and successfully run it into title without exceptions. Intial commit is here https://github.com/igorko/flare-engine/tree/SDL2port. I needed to make few minor fixes for master. Currently screen is black, I should forgot something. Also it needs few more functions to be implemented. One problem is with UtilsDebug.cpp, but we can disable it.

[igorko]

Thanks to @dorkster current SDL2 port is almost done. But I have problems with settings changing. Pressing Ok in settings menu closes the game (with some Texture errors/warnings in console).

[igorko]

http://sdl.5483.n7.nabble.com/render-fail-after-resize-window-td38388.html

[igorko]

Hi guys. I want to share with you sdl2 port progress. Currently there are some problems with settings changing under Windows(DirectX). I have made some investigations. Here are results. I was able to make resolution changing work in next way:

1. removed resolution change confirmation dialog
2. destroyed all gamestateconfig textures right before applying video settings
3. avoided executing the remaining gamestateconfig code after requesting gamestatetitle
4. destroyed icons right before applying video settings

So looks like solution of Windows problems should be make sure we destroy all textures before we recreate renderer (see forum link above)

This solved most issues but I still have next problems:

1. Changing fullscreen mode exits the game
2. In some cases I still get broken textures on screen (if I try to change settings after trying load game or credits screen). I guess this happens because in these cases we don't free some textures and get memory corruption.

As suggested by forum post we could try to make thigs in next way:

1. Add textures counter to externs.
2. Increase it on every texture creation
3. Check if counter == 0 when we apply settings.
4. Move resolution changing to separate gamestate.
5. Make sure to not execute gamestateconfig code anymore if requested game state is not null. Currently some of currentstate code is still executed before currentstate is changed. And if we free gamestateconfig textures and then try to execute this code we will get crash. This will give us next things:
6. Make surewe don't leak memory in any of gamestates
7. I hope this will fix textures corruption and fullscreen changing.

Here is a diff of how I have made resolution changing work.http://pastebin.com/9Er5C6A3 @dorkster Could you try to play with textures counter and moving confirmation dialog to another gamestate? I have synced sdl2port branch with master and added few more fixes.

[igorko]

@dorkster With your fixes and disabled confirmation dialog I get one texture not freed somewhere. Or I missed something, or it's really not freed. I have commited counter code.

[dorkster]

@igorko I found the texture that we weren't freeing and fixed it: https://github.com/dorkster/flare-engine/commit/1dc4f082b4a44f37aed8469498bdd3caaabdfe31

Update: I moved the resolution confirmation dialog to a new game state. Please look at my branch and test on Windows.

[dorkster]

The only remaining task for SDL2 support is an implementation of SDL2RenderDevice::checkPixel(). This function is used to have pixel-precision when clicking on map tiles.

Currently, I don't know how we should go about implementing this. From what I've read of the SDL2 docs, there's no proper way to read pixel data from an SDL_Texture like we could with SDL_Surface. The general solution I've found on various forums is to store an SDL_Surface when loading the image, and operate on that in the same way as we did with SDL1. However, I suspect this will nearly double memory usage (two copies of the same image). Thoughts?

[igorko]

@dorkster First way See http://stackoverflow.com/questions/19107476/get-pixel-info-from-sdl2-texture

Second way (requires Texture type: SDL_TEXTUREACCESS_STREAMING) http://gamedev.stackexchange.com/questions/63617/altering-pixel-value-in-an-sdl2-texture http://gamedev.stackexchange.com/questions/62705/how-do-i-access-the-pixels-of-an-sdl-2-texture

[clintbellanger]

Confirmed with Zear that SDL2 probably won't ever be supported on those linux handhelds. He also noted that some hardline free software people might not like SDL2 because it relies more on binary blobs of video cards.

So Flare 1.x will definitely stay with SDL 1.2 as the main implementation.

[dorkster]

@clintbellanger Sounds fine to me. The SDL2 port can be build with either version of SDL. In fact, SDL 1.2 is the default when building with CMake, since there are no proper *.cmake files for SDL2 (I used pkgconfig as a work-around).

[Bertram25]

@dorkster In case it may help: https://github.com/Bertram25/ValyriaTear/blob/sdl2/CMake/Modules/FindSDL2.cmake https://github.com/Bertram25/ValyriaTear/blob/sdl2/CMake/Modules/FindSDL2_image.cmake https://github.com/Bertram25/ValyriaTear/blob/sdl2/CMake/Modules/FindSDL2_ttf.cmake

@clintbellanger

because it relies more on binary blobs of video cards.

Out of curiosity, what do you mean exactly? And what kind of linux handheld products are you talking about?

Regards,

[clintbellanger]

"binary blobs of video cards" by this I mean SDL2 relies on closed-source drivers for video cards. Which some Linux advocates don't like to use.

Example linux handhelds are GP32x and GCW-Zero.

[Bertram25]

Hi @clintbellanger

Sorry to bother again, but I'm quite surprised with this piece of news: O.O Have you got any links documenting this? Because that sounds like a nonsense to me. I truely think SDL is a refined wrapper around lower graphical and input logic, in order to ease the devs life. And as I can see, it can be compiled against many "graphical servers" depending on the OS. What the servers themselves are doing is another story, of course. But as I could see, linux open sourced drivers have seen many progress lately and mesa is slowly but surely catching up in terme of gl specifications and performances.

Yet, if you can prove it to be true, I might have to revise my plans for VT as well.

Example linux handhelds are GP32x and GCW-Zero.

On september, Zear told that SDL2 was ported to GCW0 even if not properly tested yet. http://boards.dingoonity.org/gcw-development/%28question%29-about-sdl-for-the-gcw0/ I cannot imagine open sourced consoles not supporting the latest version of what is the edge of the linux graphical libraries.

I don't want to spam the issue here, but this IMHO important enough to ask.

Best regards,

[igorko]

@Bertram25 As already said you can take SDL2 port and build it for platform you need. It will be just not included in 1.0 release.

[clintbellanger]

@Bertram25 here's my question and Zear's answer, including his notes on SDL2 coming to the GCW-Zero.

Clint:

Some of the guys working on Flare have it running on SDL2 in an experimental branch. But I don't want to switch to SDL2 support by default if that leaves behind too many platforms. Do you know (or how to find out) how well supported SDL2 is on various handhelds?

Zear:

I can easily give you an answer - SDL2 only supports GPU accelerated video backends, thus to my knowledge the number of non-android devices supporting SDL2 is zero and this number probably won't change much :) We will eventually add support to SDL2 in GCW Zero (already have a hacked build running first tests), but as of now SDL 1.2 is the only option. I am not too familiar with differences between SDL 1.2 and 2.0, but if it's possible, I would keep a SDL 1.2 compatible renderer (just think of all these hardcore GNU/Linux uses who refuse to play Flare because SDL 2.0 forces them to use GPU blobs).

[clintbellanger]

I'm open to this idea too: we could consider making SDL2 the default but keeping a healthy SDL1 implementation in a branch. If you guys want to discuss the pros/cons I'm down.

[dorkster]

The SDL2 port is experimental at this stage, so I wouldn't feel comfortable making it the default. I personally thing that the SDL2 port should reside in another branch/repo. Cmake let's us build either version with the -DUSE_SDL2 flag. Unfortunately, building without cmake is trickier, so we can't just use the one-liner that's in the readme right now.

I propose we keep SDL1 the default and keep SDL2 in its own area. The question here is: new branch or new repo?

• a new branch would make the SDL2 port easier to discover, but tagging could get messy. Assuming I'd be maintaining the branch, it would be more risky since I'd be pushing directly to this repo, and accidents happen :)
• a new repo (I'd create this) could have it's own tag setup. Maintenance would be happening outside of this repo, so it'd be less prone to accidents

[igorko]

Using SDL2 in Goblin Warrens I get next error message: Couldn't load image: Texture dimensions are limited to 8192x8192 Strange that I see it not every time. Added debug info and it was: mods/fantasycore/images/enemies/antlion.png It's size is 8293 x 83 Pixels The question is:

• can we limit spritesheet size? (@stefanbeller)
• is there a rist that we will go out of bounds when using HD graphics?

[dorkster]

I think the spritesheet packer should be changed to make output images as square as possible. Let's say we pack antlion.png into a perfect square (probably won't happen, but it should be close):

8293*83 = 688319
sqrt(688319) ~= 830

So antlion.png could be around 830x830 pixels, well within the mentioned bounds. If we double the size for HD graphics, it's only 1660x1660, which is also within the Texture bounds.

Fun fact: My file manager (spacefm) fails to thumbnail some of the current narrow sprite images, since GDK pixbuf scaling fails beyond a certain aspect ratio.

[Bertram25]

@clintbellanger Ah well, now it is much more understandable to me, thanks for sharing the details. :) While I'm convinced the GPU blobs use will hopefully fade in time with open-sourced replacement (with nouveau and such), I can understand it can be seen as a problem when the embedded graphic hardware has got no hardware acceleration.

Yet, the X server and (I need to check) probably Wayland provide a backend to handle graphics when there is no accelerated graphics hardware. The problem is simply that this is slower, of course. I wonder what the SDL team thinks about the issue. It must have been raised somewhere somehow, right? (I'll try to find out.)

Disclaimer: My point is not to criticize and such. What you guys do is fantastic and reasonably thought. My point is just that I found "too bad" to see the project split into two just because some random technology might be just too young for now. But also to check whether I might be the one being wrong here for anything I'm unaware of.

Anyway, I'll stop here. Thanks again for your answers.

[stefanbeller]

yeah we need to change the cost function in the sprite packer to favor more squared packings. So I think the next higher power of 2 is crucial for the packing. So 830x830 is roughly equal of cost to 1024x673. However 1025x670 would be way more costly.

I think I implemented that already into the spritepacker, when optimizing further there. So in fact I did not sell https://github.com/clintbellanger/flare-game/pull/353 right, which does weight in the next power of 2 for height and width of an image.

However I messed with the commits there as I thought the PR would be accepted only for reasonable improvements.

I'll check the code for sprite sheetpacking tonight and open another PR.

[stefanbeller]

Ok, I added the constraint to prefer more square like shape instead of thin and long shapes. The spritesheetpacking repository is up to date. I also worked towards an easier use for mods using the sprite sheet packing.

[igorko]

I guess this discussion can be closed as we have come to one point. @stefanbeller Please post any info about textures size limit in flare-engine-next issue here https://github.com/dorkster/flare-engine-next/issues/4