Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - therocode

Pages: 1 2 [3] 4 5 ... 9
31
SFML game jam / Re: Game Submissions now open
« on: June 06, 2014, 09:26:51 am »
Hey!

We didn't expect that we would be the only submitters haha.

In any case, the reason why we submitted with broken links like that is that the submission form had no star (*) on the binary fields so we though no binary was needed. Then 3 minutes before the deadline when we tried to submit, it said "error, at least one binary required!". Since there was only 3 minutes left, there is no way it would be possible to compile, pack and upload a binary haha.

Also, in my opinion, having a binary requirement is bad since people are on different systems anyway. I myself am on linux and getting a windows binary would be a big hassle. A linux binary on its own would require the player to have not only linux installed but also all dependencies' .so files available. Unless I go through the effort of setting all my dependencies up for static linking, which is something I'd not want to go through just to submit a binary with a gamejam entry, when the source is readily available anyway.

So for me, that requirement creates more complications than what it solves. But sure, if anyone _wants_ to submit binaries, then that's just a good thing. :)

For the ones who want to test the game, me and Kim are just about finished with porting the game to the web using emscripten, and when that is done, we'll post a link here for people to try out. Note though that this version doesn't use SFML since SFML is not emscriptenable, but it's the same content anyway.

32
General discussions / Re: Thanks guys!
« on: May 26, 2014, 08:40:37 am »
Yeah, you better keep your head on! Coding is hard without it, haha. :)

33
I would agree that if I made a video player, I would want this feature. I think it is retarded when video players get interrupted by the screensaver. It is much more annoying to manually deactivate the screen saver every time I want to watch something. Often you don't even remember to, until it happens in mid-film and you get annoyed and have to pause and deactivate it.

So my opinion is that if SFML is meant to be able to be used for video players and other such passive visual media, then I am all for this feature.

34
General discussions / Re: SFML 3 - What is your vision?
« on: May 02, 2014, 05:25:39 pm »
Easy solution: using Camera = sf::View;

:D

35
General discussions / Re: SFML 3 - What is your vision?
« on: April 28, 2014, 10:13:10 am »
Support texture packer.

The other week I tried using texture packer but it is not a free product. You have to pay to use it and the trial version makes some sprites red with the text "trial version" on them. IMO SFML which is a free library should not integrate with non-free products.

36
General discussions / Re: sf::Shader -- API to set uniforms
« on: April 27, 2014, 11:16:50 pm »
If SFML defines some maths functionality like its vectors and the proposed matrix, there will always be a fuzzy border between how much functionality should be provided and not.

It will also cause issues in the cases where users want maths functionality and are forced to copy over values between their own maths stuff and SFML's maths stuff. This is not a smooth way of interfacing.

In my opinion, a nice solution would be to deprecate all the sf::Vectors and make it use GLM. The drawback is obviously that it is another dependency, but in my opinion it is worth it. It is also headers only so the dependency is light.

This would give all users access to any kind of linear algebra maths they would need out of the box. It would also mean perfect integration between SFML and the user's maths code. Furthermore it would contain ready  types for all GLSL uniforms since GLM is based on GLSL. It would also be no maintenance for the SFML developers since the responsibility for the maths stuff is at the GLM crew.

Has this been considered before? Are there more drawbacks than it being a dependency? Or is that a big drawback enough?

37
General / Re: How to handle dead characters in game?
« on: April 27, 2014, 04:53:53 pm »
If you don't have thousands of characters (or if your game is designed poorly) then leaving dead characters as corpses is not a problem at all. You can flag them dead like your idea and let them display a corpse image and stop doing their logic. You can even delete the main object and spawn a lightweight corpse object just for display.

That being said, if you do not want to have them visually around after their death, just delete them. I assume you store your entities somewhere, for example in a vector. In that case, just pop them off it.

38
SFML projects / Re: School management simulator
« on: April 27, 2014, 12:26:06 pm »
Looks fun, I love these types of games, being a big fan of Dwarf Fortress. :D I like the idea of the school setting. That seems unique and I can imagine many funny quirky situations arising.

I am myself working on a game in the same genre but managing a space station. Haven't really gotten anywhere yet though haha.

39
General discussions / Re: SFML 3 - What is your vision?
« on: April 27, 2014, 07:31:32 am »
I'm not asking for the whole kitchen sink (I said "enhanced," not "advanced"). The thing is SFML already provides vectors and matrices. And these aren't things that can be stripped out of SFML, as coordinates and transforms need to be specified for SFML to do its work. But these things SFML provides have no support for basic linear operations (dot/cross products, projections, etc.). It would be nice if common operations and data types (i.e. quaternions, particularly if 3D support is added) were supported.

Still, it seems to me that SFML's math classes are there to make SFML work on the inside, not to provide advanced maths functionality to the user. If maths is needed in your project it is still super easy to grab GLM, it is a very light dependency being headers only.

Although, in my opinion the best alternative would be to discard the SFML maths classes and instead use GLM directly. That way you can do all the maths you want and it would still integrate well with SFML and you would not have to rewrite a lot of maths.

40
General discussions / Re: SFML 3 - What is your vision?
« on: April 26, 2014, 05:05:58 pm »
Worst you can do is to expect people to install hundreds of additional libraries to make their games and apps work, just because "they can do it". We are not talking about SFML 2.x, but SFML 3 and it's long-time project, so there is no reason to reject any idea just because it's "time wasting" and "it is already done in XYZ library".

By this logic you would expect SFML to ship AI, state management, path-finding, physics, scenegraph management, dynamic resource loading, a whole set of GUI components, astrophysics simulation, car assembly algorithm, face recognition, and who knows where we'd stop.

SFML is a multimedia library, not a game development suite. I don't believe there are enough developers to cover up for all the time and management that would be needed if SFML would greatly increase its scope. Also, just because SFML doesn't include everything does not make you need "hundreds" of dependencies. You only need to grab the ones you want.

I would rather see that time is put into refining what the concept of SFML is, make the API great, extend its feature set within the scope and do it well like no other multimedia library out there.

41
General discussions / Re: SFML 3 - What is your vision?
« on: April 26, 2014, 09:03:54 am »
Things I really want:
  • Enhanced math library (more vector/matrix stuff, up to 4D, and including things like quaternions)

IMO there are absolutely no reasons to add advanced maths stuff since there are other libraries doing that and being focussed on it. GLM for example is headers only and has heaps of functionality related to 3D graphics maths. Adding a maths module to SFML would only mean more maintenance and reinventing the wheel.

42
General discussions / Re: SFML 3 - What is your vision?
« on: April 25, 2014, 11:30:57 am »
GLEW or any manual extension loading is not required for emscripten. All supported GL calls work out of the box. The graphics API needs to be ported to work with OpenGL ES 2.

Damnit Brain-fart, GLFW. not GLEW xD argh, those aren't confusing similar names at all

As I understood it you have to use EGL (+X11), GLFW, or SDL to create a window for OpenGL. I edited to list them, but doesn't SFML already use GLFW in parts?

Also the Android port I'm guessing uses EGL, so there's already that code available.

Aah, then it makes sense :D and yeah you need to use them to create a window, but that can be separated easily into a backend probably. Not sure about GLFW in SFML.

I'm a bit confused. What role is SDL playing in this all? Because I don't think it's really an option to have SDL or GLFW as dependency of SFML... ;D

No, not as a dependency. Emscripten provides that automatically when you compile using it. So you would use the SDL/GLFW API in the emscripten backend as an underlying base for window/event stuff and then you can compile it with emscripten. No need to grab or install SDL or anything.

43
General discussions / Re: SFML 3 - What is your vision?
« on: April 25, 2014, 11:17:59 am »
Perhaps we can elaborate what changes are exactly needed to make this happen.
Of the top of my head:
The Windowing API would need to use GLEW to create the window and handle events without any OS specific code (or at least the OS specific stuff is #ifdef'd away).
The Graphics API needs to support the WebGL subset of OpenGL (which is basically OpenGL ES 2).
Audio API.
Networking would need porting to WebSockets/WebRTC. Probably easier to drop support of it for Emscripten.

GLEW or any manual extension loading is not required for emscripten. All supported GL calls work out of the box. The graphics API needs to be ported to work with OpenGL ES 2. Many OpenAL functionalities are supported out of the box by emscripten. Events and windows can be managed using SDL's API out of the box and that could be written as a backend for the window stuff. Networking I have no knowledge about. :D

44
General discussions / Re: SFML 3 - What is your vision?
« on: April 25, 2014, 07:42:39 am »
Quote
Context stuff.
I totally agree with that.
Awesome! :D

Quote
Would be neat to have web-compile capabilities for SFML as well!
This is less likely to happen. But if someone provides an implementation, why not.
Ah, any particular reason why it is not likely to happen? Running things in the browser is all the rage these days.

45
General discussions / Re: SFML 3 - What is your vision?
« on: April 24, 2014, 09:17:09 pm »
Two things that I'd find awesome are these:

1.
If possible, render and audio context management. In other words, separate the contexts out from the Window and wherever it is stored for the audio into sf::RenderContext and sf::AudioContext and provide an API for using custom contexts. This would make it way easier to integrate SFML in certain situations and would mean better ownership-based design with less magic stuff going on. That magic stuff is sure arguably easier and more simple but I find that in the long run, it is a drawback.

2.
I am a fan of Emscripten and I have written some code in my own game framework to make it compatible with emscripten out of the box. This means that any game I make with my framework, I can easily compile to have it run in the browser. Some silly examples: bladepit  ants   space. As you can see they run with good framerates and it is just javascript and webgl so will work on pretty much any browser that supports that. :) Would be neat to have web-compile capabilities for SFML as well!

For emscripten support, what is required is a special way of handling the main loop so that the browser doesn't freeze, and compiling all the dependencies, and tieing browser events to the SFML events. It could be hard to support _all_ the features of the Window module since the browser app acts pretty different to a desktop application but that can be alright imo as long as it is well documented.

Pages: 1 2 [3] 4 5 ... 9