-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SFML Port (Master Task) #105
Comments
Related tasks:
@Quintus @Luiji @brianvanderburg2 @sauer2 --- I'd be interested in your thoughts. |
To be honest, that more or less sounds like a complete rewrite in terms of efforts. |
I'm just mind-blown by all the bullet points. =( Let's remember to pace ourselves here. I doubt we're going to get the rendering system or the physics system finished by 2.0.0. @sauer2 is right that this is a lot of effort (though I don't think it's nearly a complete rewrite). For transitions like these we'd need to do a lot of incremental changes. For instance, we'd slowly migrate off our use of OpenGL data structures where OpenGL isn't being used directly, isolate OpenGL usage to few enough functions that it's practical to rewrite them using a new API, etc. The way I see it is this should all be seen as a background process while we're doing everything else. I'm still struggling to get CEGUI to work while CMake keeps breaking, and there's a plethora of features that we can implement that don't depend on any of this. TL;DR This should all be considered low-priority, long-term concepts. |
I'm sorry it's so long, but I wanted to express that there are other things to consider before just assuming that we should replace OpenGL with a higher level library or replace physics with a library. I probably should have left out the geometry and image processing items for now, but this is actually a discussion about both development philosophy and what solutions to use. If you want I could downsize the above post a bit, but most of it was points I wanted to convey. I did try to find a compromise, though. EDIT: Trimmed the above post down. |
I'm also going to point out that SFML and Allegro both allow direct OpenGL access (which I've used successfully before) so we're not giving up any control, just using external routines to simplify the code. Though, for the purposes of SMC, I honestly don't think we'd ever need 3-D primitives, even for some of the fancier effects. To exemplify how far SFML and Allegro work with direct access, I've written a 3-D game on top of Allegro just fine. Small bits of custom OpenGL in our code is fine. My main grief with SMC as it is is that we use SDL and implement a 2-D engine directly on OpenGL when we could replace SDL with something that comes with a 2-D engine and simplify our OpenGL use to basic 3-D code (which doesn't even exist yet). Also, could you please extend your description of a "partial 3-D mode"? There's a few things I can imagine that meaning. |
I saw this for Allegro but didn't know SFML had it. To your point, OpenGL could be used with these later if 3D is needed. My reasoning was that a fully 3D API would allow easy 3D usage if needed later without necessarily delving into things like GLSL. Are all API calls hardware accelerated through OpenGL?
When doing a 2D projection rather than a perspective projection (3D depth), you can still make use of z coordinates if needed. 2D is a subset of 3D.
If we end up using a high level API that provides the windowing functionality SDL provides, I also think we should get rid of SDL.
Yoshi's island is primarily a 2D platformer game with sprites. However, when you fight Baby Bowser at the end, you can throw eggs in 3D (while moving in 2D) to defeat him. This game also has a number of platforms that rotate in 3D while you interact with them in 2D. I'm not suggesting we do this any time soon, but I think it makes sense to make decisions that easily allow for it. What thoughts do you have on physics API's? Thank you for sharing your thoughts. |
My whole idea is replacing our current SDL installation. The thing is, the latest SDL variants come with the same functionality that SFML and Allegro do, so it's all about API preference.
I never really understood why SMC needed a full-on physics engine. I imagine FluXy had something in mind I didn't know about. |
What do you mean by SMC not needing a full-on physics engine? The wiki discussion I found on the main site made references to a switch to the Bullet physics API. Do Allegro / SFML support any type of lighting system (#94)? |
I'm aware of the wiki... I know that it's been on the to-do I just don't know why it's been on the to-do.
No, but they do support shaders so we can implement that ourselves if we so desire. |
A very interesting discussion. Thank you @datahead8888 and @Luiji, I really apreciate it especially as I don’t know about graphics programming.
I also have this feeling... This is not something that is open to arguments anymore, so I suggest we will vote on what to use.
A real 2D physics engine would remove the need to code physics ourselves. It reduces code maintenence work and gives a more accurate physics feeling in SMC. @datahead8888 has pointed out to me that writing really good OpenGL code is hard, and an abstraction layer such as Ogre, Irrlicht, or whatever will do it better than an average developer, plus the ability to also generate DirectX code on win32 platforms (although I have to admit that enforcing OpenGL even on Windows is something I would without having any problems with it -- go die proprietary solutions). Therefore, I think relying on an OpenGL abstraction layer is a good thing IMO. As said, the final decision on which one will probably be decided with voting. Vale, |
It sounds like the group has decided to use libraries for higher level rendering & physics, unless any of the others want to cast dissenting votes. My suggestion is to wait on voting as to what API's to use until someone can do some research into what the 3D alternatives offer. I think it might make sense to consider an API that directly supports lighting if possible, and I think there can be advantages for 3D support in case we unexpectedly need some 3D processing (another good example of this is using z coordinates with blending (transparency)). I don't really have direct experience with Allegro, SFML, Box2D, Bullet, or Ogre, but I think it makes sense to allow some time to look into them and not simply choose what looks easiest for 2D. This would allow for a more informed decision. There's no rush on this. @Luiji - thank you for reading through my whole post above and having patience on a hot topic. It's appreciated. @Quintus - thank you, too. |
Here's my basic opinions on all the libraries available, for reference (as I've used all of the ones discussed but the latest SDL 2, where I've only peered at it's documentation). Note that all of these are abstractions on top of OpenGL, and some (Allegro, Irrlicht, Ogre) of them are abstractions on top of DirectX. I know Allegro and SFML allow direct access to the underlying system (OpenGL/DirectX) and, in most likelihood, they all do.
I have no opinion on the various physics libraries because I've never found a need to use them. Before we do anything on that I think we should all fully read this http://www.learn-cocos2d.com/2013/08/physics-engine-platformer-terrible-idea/ that @datahead8888 linked as a sort of cons to go with all our pros before voting on that or whatever we do. I've only skimmed through it and I want to get a full reading in before saying anything else on that matter. So yeah, there's where I'm at. I've worked with a lot of graphics APIs because there was a summer where I was just trying to find which one I liked best. For awhile there it was Allegro but lately I've been using SFML. Ogre and Irrlicht only crossed my desk when I was trying out 3-D graphics programming and even there Irrlicht installed like a breeze and Ogre took years (in tech time). I often use different APIs for small projects to give myself a refresher so I can work with them if I ever have to (the same thing I do with programming languages). |
@Luiji Apart from the fact that a jump and run game doesn't suit to real physics - which engines try to simulate - it may also require a total rewrite of the game loop and the timing dependencies to suit fixed timesteps. |
@Luiji, thank you, now I understand why you were raising concerns about 3D rendering libraries. I would be curious if there is a 3D rendering library that is more light weight and/or that supports lighting systems. I think I'll make a post on gamedev.net and see if anyone there can offer guidance. If I had to choose between Allegro and SFML, I would probably tend to choose the one that's more widely used. If we don't end up using a physics / object collision library, we could try to find some existing slopes collision code that has a permissible license and use that. We are already using some borrowed object collision code under the MIT license from what I saw. Super Tux ran into a lot of nasty issues when they did slopes themselves. It would be interesting to look into an implementation, though. If we don't end up using a physics library, I'd personally be interested in upgrading Open GL, as I'd view this as consistent with using our own physics system. Also, the performance issues in writing your own renderer are less prominent in 2D than in 3D. That's just my personal opinion, though -- the group can decide whatever it wants. |
I read through the entire article and got the feeling the author doesn’t want to have real physics. A physics engine is fine if you want to implement real physics. If you don’t want real physics, then of course you shouldn’t use a physics engine. If for example you start out with the need "my object is not allowed to bump off the ground when landing" (which is real physics behaviour), then the entire comparison between using a physics engine and implementing all the behaviour yourself is flawed. A physics engine is not meant to cater for such cases, and if you want to force it into that, you of course have to override its behaviour. The article made clear one thing to me, though. Do we want real physics in SMC? It would be a nice difference to almost any other platformer out there. On the other hand, people do not expect this from a platformer. But still, we have a performance problem in SMC. Has anyone run SMC through As for the OpenGL library thing: I agree with @Luiji that Ogre is waaaay to large. Even Irrlicht appears to not really suit us. Note also that SMC currently uses SDL 1.x, so it may be easier to upgrade to SDL 2.x than to change the engine completely. But even if we stay with SDL, we should remove the custom OpenGL code in SMC anyway and rely on what SDL (or any other engine) gives us except for special cases (which should be commented in the code as to why). If upgrading to SDL 2.x appears to be so much work we could even use another engine, then we can do that as well. C or C++ doesn’t matter I think, good C libraries also use object-oriented programming by accepting their notion of Valete, |
@carstene1ns posted a first hit on SDL 2 support: https://paste.xinu.at/NIZ5Ov/ Vale, |
I'm not saying we should not use a renderer (Allegro / SDL / SFML), but there was a point that FluXy brought up: At http://www.secretmaryo.org/phpBB3/viewtopic.php?f=6&t=9120&p=41892&hilit=Allegro#p41892 he said:
Here FluXy was suggesting OpenGL itself and seemed to suggest that OpenGL ES is a good way to get mobile games support. Whatever we decide on using a renderer or using bare OpenGL should take into account mobile support. Also, @carstene1ns challenged whether or not support for the old OpenGL will be dropped anytime soon. FluXy had the same response at this (old) posting: http://www.secretmaryo.org/phpBB3/viewtopic.php?f=6&t=2885&p=17575#p17575. |
@datahead8888 SDL, Allegro and SFML are not rendering systems.
About OpenGL support, that is a non-brainer: Here is an article (from 2013) to give you an idea what that could mean: |
So, I dug around the OpenGL website, and headed over to the official OpenGL FAQ, which then in turn provided me with this fine article: https://www.opengl.org/wiki/Legacy_OpenGL I can confirm we use at least the
I derive from that:
The article on legacy OpenGL closes with this:
That is, 2.x OpenGL hardware is not even considered anymore. Judging from this information I guess we need to move to a newer OpenGL version. Opinions? Valete, |
@Quintus Judging from http://stackoverflow.com/questions/8044882/difference-between-opengl-3-x-and-4-x it seems like 3.x and 4.x aren't completely different, but differ in range of features. I'm not the developer, but if i were, I would - if painless enough - limit the used features to 3.x to support as many platforms as possible. So that, once 3.x is deprecated, only a compilation switch to 4.x is required. |
@Quintus, if our understanding from that article you linked to is correct, this issue is more urgent than the CEGUI upgrade. I was speaking to grumbel, the project lead on Super Tux, and he quoted these sources. He initially was of the opinion that an OpenGL upgrade is not necessary for Super Tux. NVidia - From https://developer.nvidia.com/opengl-driver :
AMD - From: http://developer.amd.com/community/blog/2011/08/10/amd-releases-catalyst-beta-drivers-for-opengl-4-2/
grumbel also said:
He thus said the upgrade may break the game on many cards (probably a bit older ones I assume but still a possible problem). When I brought up the points about Mac OpenGL support, OpenGL ES support (mobile device support), and support on some Linux distros, he then said:
Toward the end of the conversation, he conceded that Super Tux may eventually have to have two versions of the OpenGL code to work on everyone's machines. He brought up an interesting point about SDL 2:
Super Tux actually is using SDL 2 with Open GL. How did they do it?
|
Urrrgh, what’s that. @Luiji, please pop in and share your thoughts on this. So SDL2 can’t be mixed with custom OpenGL code. This may be good or bad, depending on whether we actually want our own OpenGL code. In any case, we have not the resources to provide two renderers as SuperTux does, therefore we have to make a decision on that. Both NVidia and AMD, manufacturers of the most graphics cards out there, have stated they won’t drop OpenGL 2.x compatibility if I understand correctly. It would be interesting to know if Intel doesn’t do it neither, then we would have covered all three big manufacturers of graphics cards. Assuming they also maintain 2.x compatibility for now, and further assuming we decide to use raw OpenGL rather than relying on an abstraction layer, I would suggest to If we decide to use some abstraction layer, SDL2 for instance, we delegate the problem to the abstraction layer. It won’t go away, but then the devs of the abstraction layer have to solve it, and they are probably more knowledgable about that than we are. Valete, |
Without our own OpenGL code we may be pretty limited on task #94 - the lighting system, unless it turns out SDL or another API provides equivalent functionality with shaders on hardware. The reason the original SMC used SDL was because this was a common way to handle the Windowing system and to connect it with OpenGL. I'm guessing the paradigms are changing, but I'm obviously not up to speed on the latest SDL version right now.
My understanding was that Mac and mobile systems are still issues. We probably don't have any plans to move to mobile soon, but we don't want to handicap ourselves. From what I've heard, though, it's usually hard to control a 2D platformer on a phone unless you plug a controller into it.
At this point, it'd be worth considering writing two renderers (as classes) rather than having a lot of #ifdefs. We would also need to research how to test each separately, possibly on different cards.
This is obviously more convenient, but there are some things that OpenGL is very good for that we might want to leverage (in the issue list). I'd be interested if @Luiji thinks Allegro/SFML might solve these big problems for us. |
@Luiji - you said in #103 that Allegro will add bounds to an image if it is not a power of 2. From this it sounds like it probably deals with both old OpenGL (needs padding to get to powers of 2) and newer OpenGL (should not need padding). If this is correct, Allegro may be a possible solution to the main problems we listed above in which different versions of OpenGL may break on different machines. Do you know if SFML can work with alternate versions of OpenGL? After this is resolved, we could still consider using GLSL (OpenGL Shading Language) with Allegro/SFML for tasks such as #94 (the lighting system). In order to be 100% compatible with all cards, we may have to allow this feature to be turned on/off automatically based on card support. I would like to post a question about this on gamedev.net and stackoverflow.com (and maybe the Allegro & SFML websites) but may not get time for at least a week. I'd also be curious to see if they agree with our conclusions on the physics system. stackoverflow.com did work for resolving our nasty formatting merge conflict problems. |
From what I read of the Banana Bread demo (Unreal 3 compiled to Javascript) was that it ran at about half the speed of the native code. While that doesn't sound great, it still looked just fine in practice, and I can't imagine TSC needing the same specs as Unreal. |
Before the discussion grows out of bound with regard to Emscripten,
Our primary goal should be the desktop, and if it runs in a browser, I’d Valete, Blog: http://www.quintilianus.eu I will reject HTML emails. | Ich akzeptiere keine HTML-Nachrichten. |
@Luiji @datahead8888 @brianvanderburg2 Currently, TSC uses SMC’s old SDL1 + OpenGL2 combination (because SDL1 was horribly unperformant on itself). I am under the impression that given the discussion in #10, everyone is fine if we switch to SFML. Note this does not imply SFGUI, which is a separate topic. CEGUI can still be used with SFML as well. Is everyone fine with switching to SFML as the main rendering framework then? Valete, |
I'm not a TSC dev so in the end it's your decision anyway. The time I used SFML (2.1) it worked out nice, but from what I heard on reddit you might run in two problems:
Also, compile times might get worse. That's the price you pay for a modern C++ API. |
The 2.3 release is not too far in the future as far as I can see. The guys in
Are you referring to this? http://www.sfml-dev.org/tutorials/2.2/graphics-vertex-array.php To this? http://www.sfml-dev.org/tutorials/2.2/window-opengl.php SFML works just fine without having to write a renderer. If you want, you can drop to bare OpenGL for performance, but it is not required. However, I’m new too all this, so I’m going to wait for a comment by @Luiji on that topic who said he has worked with it. Vale, |
Yes. Good to see those two issues won't be a problem. |
I would like to pause a moment and discuss both of sauer2's 2 new points a little more before finalizing this decision.
From what Quintus said, it may not be a problem, but I'd be curious if Luiji has any concerns. I'd like to read the SFML team's discussion some more when I get time.
Many higher level API's akin to SFML allow you to override a draw() method (if object oriented), in which you write the logic to draw everything to the screen. I would like to understand this point a little more before making a decision if possible. Also, we have a second ticket that also talks about the OpenGL upgrade. Can we close it as a duplicate, or do 2 tickets still make sense? |
I have experimented a bit with this due to your suggestion and found that it’s really easy to use. I have implemented an ungly and simple example of creating an object that consists of several sub-images that are handed to the graphics card at once as one single blob:
It is possible to add as many elements as necessary to the Scenery instance, they will all be thrown onto the GPU in one step as one single large Even me who never touched a line of OpenGL code can understand how this works <3. Vale, |
Yes, this is probably duplicate then. Vale, |
Yes, I realized afterwards I misread sauer2's point. He's not talking about implementing your own draw method. |
The only thing I'm concerned about is this "OpenGL Core Context" thing, but I honestly have no idea what you guys are talking about in that regard. I doubt compile times will be effected in a way that's detectable to a human being. Rendering can definitely be done efficiently. The main thing we should do to reduce compile times is reduce the code base. Switching from CEGUI to a less complex environment would help in that regard, so long as the target is actually less complex. That's for a different discussion, however. |
Ok. You are the experienced game dev, so if you say it is not relevant then I will not doubt your judgement.
As in "remove all the backward compatibility" ;-). Honestly, the compilation time is something I do not worry too much about. I’ve never seen a suggestion to optimise compilation time before. One never has seen everything I guess... So, here’s the obligatory XKCD (© Randall Monroe, CC-BY-NC 2.5): Vale, |
Approaches are ranging from better languages (basically every modern That's not to say I'm a professional C++ dev, I just watched some talks. Unrelated: Want a pro-tip for guelkerdev? Make the text panels opaque, @Luiji: Out of interest, are there plans to drop the boost libraries, |
Talks are great :-). Except all the talks I have viewed were Ruby talks... 🐘
Errm, sauer2, this is nice that you make recommendations on my (more or less) commercial site, but I think this is not the place to do so.
I was actively looking for a rendering library that does not depend on boost, so the short answer is: yes. The long answer is: Not right now, wiring out all the boost stuff will take time. Vale, |
I take it then that I can start with SFML porting now? :-) ...yes I know I am pressing with this... I just want to start :-) Vale, |
|
I like how SFML is C++ based unlike SDL. Does it have decent support for all Linux/Windows/Mac, and is it future-stable? SDL looks like it is here to stay, but I've only recently heard of SFML. |
It isn't backed by a company, but... SFML has been there quite some time now and Laurent Gomila has If that's what you mean by future-stable. It runs on Linux/Win/Mac, support for IOS and Android is in the makings. Am 23.03.2015 um 23:46 schrieb Brian Allen Vanderburg II:
|
Following @datahead8888’s more sensible approach to porting TSC to SFML, the main work on this task (and its subtasks) has now shifted to the Valete, |
Porting is nearly done. Remaining is solely issue #516; once that is implemented I will merge Valete, |
This is a task to decide whether to use 3rd party API's for physics and rendering as well as development philosophy for all libraries.
Thoughts on each sub system
There are 3 basic philosophies on how to apply them:
If we take option # 1 for one subsystem, I think that policy should be consistent across all subsystems. In regards to complementing physics systems, I do not mean to run out and start reimplementing dozens of Bullet features. I mean that we might consider extending a physics API for an additional physics feature or implementation. In such a case, we would normally interface with the API (perhaps adding a custom module) unless we had a good reason not to.
There are things I like about option # 3, but given the goals of SMC and views of the developers, I am beginning to believe option # 2 is worth considering. Please do read the article link, though.
The text was updated successfully, but these errors were encountered: