Topics

16

SFML game jam / Feature Requests!

« on: April 07, 2014, 07:37:46 pm »

Hey everyone!

I wanted to get some ideas for how to improve the game jam's website so that I can start prioritizing and then getting to work.

So..have at it! Let me know what you would like to see added, removed, changed, or whatever.

17

D / DSFML to recieve many updates soon!

« on: March 24, 2014, 05:12:51 am »

Hey all!

With my term now finished I have loads of free time over the next two weeks, so I decided to devote a nice chunk of that to DSFML, specifically updating it to version 2.1.

The reason I am announcing it now is because I will be making changes to not only the D front end, but also to the C/C++ back end. Some of these changes will be breaking changes to the current API.

I'm assuming that a majority of people that use DSFML also use DUB, so I want them to be aware of this. Very soon I'll have a specific branch for DSFML 2.0, and I will post another announcement once it is up, which will also mark when development on 2.1 starts. Should be tomorrow or the next day.

18

General discussions / VertexArray's getVertexCount not size_t?

« on: March 23, 2014, 07:42:48 pm »

I opened this here instead of Feature Request because I am more curious than anything else, but I always wondered why getVertexCount returned an unsigned integer instead of a size_t.

I mean, I get that 4 million verticies is a lot already, but it just seems like using a size_t in this case, as well as in the RenderTarget's vertex draw method, makes a lot more sense in my opinion.

P.S.

Sorry if this was asked before. I did do some googling, but couldn't find anything related to this.

19

General discussions / Source code consistency

« on: March 01, 2014, 08:50:25 pm »

Basically, I was working on a project and thought to myself that I could do a much better job at being more consistent with the over all layout of my code and I was wondering if there were certain rules or guidelines that SFML uses for its source and how that process works. When I talk about consistency, I am mainly talking about how the layout of  each file is structured in terms of what things go where and in what order, and how things are named.

How does everyone here keep their stuff clean and consistent? Do you have your own set of rules you follow? Does it even matter to you?

20

SFML game jam / Jam 2 completed! Now what?

« on: February 03, 2014, 11:44:43 pm »

Hey everyone!

First off, great job to everyone that participated! I'm going to go through all the games tomorrow/Wednesday and try them out!

Also, a very, VERY big thank you to zsbzsb for not only finishing the site, but for also essentially taking over organizing everything for me during the life craziness that has been plaguing me lately. We couldn't have done it with out him!

Moving forward, I'll see if I can talk him in to continuing to help me out, especially with web development. Getting the website up was huge, and with that in place we should be able to provide more features for everyone within a more manageable time frame.


Thanks again to everyone that participated! The next one(May 30th) will be even better!

21

SFML game jam / Theme suggestions now open!

« on: January 22, 2014, 02:03:23 am »

If you weren't already aware from the thread about the jam's website, submitting theme suggestions is now live!

http://sfmlgamejam.com/

Make an account on the site and get to it!

Voting for the theme will take place in a few days.

22

SFML game jam / Website News

« on: January 20, 2014, 07:28:33 pm »

Hey everyone,

Just wanted to announce that the website will most likely not be ready in time for the jam. This is due to a lot of personal stuff, mainly me going back to school full time and I just don't have enough time to get all that I want done and still have enough time for work and school. Sorry guys, I'm just feeling a bit overloaded right now.

So, in light of this news I will be opening up another theme submission thread today so we can get that going and start deciding a theme for the jam.

Hope I didn't let to many of you down.

23

D / DSFML-C "Nightlies"

« on: December 20, 2013, 09:05:45 am »

Here are The most recent builds for DSFML-C, with the exception of the 2.0 binaries. I'll be uploading those soon, but for now the most up to date code should be just fine.

*Current*

Windows 32bit - August 8th, 2014
Windows 64bit - August 6th, 2014

Linux 32bit - July 30th, 2014
Linux 64bit - Auguest 2nd, 2014

OSX - August 2nd, 2014


*2.0*


Windows 32bit - Compiled December 19th, 2013

Windows 64bit - Coming 2014(Unless someone else wants to build them for me)

Linux 32bit - Compiled December 28th, 2013 on Mint

Linux 64bit - Compiled December 19th, 2013 on Mint

OS X - Compiled November 11th, 2013 by someone else. Haven't been tested by me.

24

D / Problems compiling DSFML-C on Linux?

« on: November 20, 2013, 10:29:24 pm »

This is kind of embarrassing as I am the primary maintainer of the binding, but I am having some issues using this on Linux. I am pretty new to the Linux world, so it could just be my own ignorance. Also, DSFML is still 2.0 based, something I hope to fix soon, so it is possible that it might have something to do with that maybe.

Anyways... I was able to build SFML as static libraries, though when I went to build the DSFML shared libraries I got this error:

/usr/bin/ld: /home/jebbs/Documents/SFML-Statics/lib/libsfml-system-s.a(Err.cpp.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
 

I recompiled the SFML static libraries with the -fPIC switch, and now my DSFML shared libraries are able to compile. Cool. The problem now is that when I try to use the shared libraries in D, I get a bunch of undefined reference errors to all of the C functions.  I use MinGW on Windows and it works fine there, so I'm not sure what's up. Any light that can be shed would be much appreciated.


On a side note, I accidentally built shared SFML libraries first and I got this error during the process:

make[2]: *** No rule to make target `/usr/lib/x86_64-linux-gnu/libGL.so', needed by `lib/libsfml-window.so.2.0'.  Stop.
make[1]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/all] Error 2
make: *** [all] Error 2
 

Any idea what that's all about?


Thanks guys!

25

SFML game jam / SFML Game Jam 2 Preparations

« on: November 15, 2013, 09:02:11 pm »

Greetings everyone!

I just wanted to give a little update since it has been a while and the next jam will be here sooner than we think! Starting December 1st I will be putting all of my current projects on hiatus and will be making the jam my main priority until it actually goes down.

I'm already going to start making a list of everything I would like to have ready before it starts, but please feel free to post any questions, concerns, complaints, ideas, etc. that you would like to see taken care of/implemented/what ever before the jam starts.

26

D / DSFML Temporary Hiatus starting in December

« on: November 15, 2013, 07:34:15 pm »

Greetings DSFML users!

I just wanted to announce that starting December 1st DSFML will be in a temporary hiatus.  I will be focusing on the SFML Game Jam to make sure there is plenty of time to make it a really really great event. I will do my best to get as much done on the library before then, however. Any major bugs will still get attention from me, but new features/improvements will not be worked on unless I feel like the jam is taken care of and I have extra time.

Regular development will resume next year after the jam is either finished or set up completely!

27

D / New version of DSFML!

« on: October 07, 2013, 07:52:23 am »

Hey everyone!

I wanted to announce that I just made one hell of an update to the DSFML binding. I've been experimenting with several things for a few months and finally decided to make it the new master branch.

What's new:
Essentially, I made two really huge changes.
Possibly the biggest thing that was changed is that I wrote a whole new C/C++ back end for the binding. I didn't write it from scratch as it is essentially a heavily modified version of CSFML, but it is tailored specifically for the binding and for working with D.

Another huge change was that instead of modules being included in a single file, I was able to split everything in to separate files with things still making sense thanks to the new back end.

Some other interesting new things include:
Everything that could be written in D code was written in D code. This means that things like Sprite, VertexArray, Text, *Shape, most of the audio classes, etc. were written in D instead of done with wrapper code around a sfXXX C struct. This of course requires more upkeep as a binding, but it was fun to do, so I did.

Hierarchies are now correct. RenderWindow inherits from Window and RenderTarget, the right classes in the Graphics module inherit from both Drawable and Transformable, and (I'm pretty sure) all of the Audio hierarchies are the same as with SFML. That sort of thing.

The SFML err ostream is now mapped into a D File struct, also named err. This means that one can now redirect SFML error output in D and write to the same location through DSFML's err.


There are also several other changes that were made, so I encourage everyone that is interested in this binding to check it out and leave me some feedback. It isn't 100% complete yet; I'm currently working on writing unit tests, code can definitely be cleaned up and made more consistent, and I still have a couple of issues to work on, but I feel like it is already very large improvement over the previous version. I also took some time and wrote a(probably terrible) tutorial for getting started.

Check it out here and let me know what you think!

28

C / Question about using Visual Studio when building CSFML

« on: September 02, 2013, 07:19:37 pm »

I had this issue when I was building my modified version of CSFML, but I also encountered this when I built CSFML too. Before I go farther I want to mention that I have only used MingW so far to compile my stuff, and this is my first experience with building SFML with VS. Basically the "problem" I am experiencing is that I am able to build the SFML static libraries no problem, but when I build the CSFML dll's, VS doesn't seem to actually link the static libraries into the shared libraries when it builds them. I only noticed this because the size of my dll's were quite small. Is there something I need to do in order to get this to happen?

Some info:

I'm not using NMake. I'm having CMake create Project files and I just open those up in VS to build them.
I'm using VS 11.

Thanks in advance for the help!

29

SFML game jam / Open GL - Yes/No

« on: August 24, 2013, 02:49:53 am »

Allowing the usage of OpenGL was debated before the first jam took place, but since we needed a definite decision for the final set of rules I ultimately decided that we should allow it. I know this was a little confusing for some and caused a bit of controversy, so sorry for that. I want to bring attention back to this topic and decide with a vote this time.

As a refresher, some reasons for OpenGL were that since OpenGL integration is an easy thing(there is even a tutorial for it) it should be allowed, plus my own reason was that I would hate to limit the jam to just 2D.

The big reason against its usage were that it isn't a part of SFML itself and thus it defeats the purpose of the jam being dedicated to SFML.

Feel free to continue the discussion if you have other reasons for/against, or if I missed any! I'm not sure how long to leave the poll open for, so for now it is open for the foreseeable future.

30

SFML game jam / SFML Game Jam Info and Rules

« on: August 24, 2013, 12:24:30 am »

These are the current set of info and rules about the SFML Game Jam. These will always be kept up to date if any changes to the rules occur.

Time Frame:
Participants are given 72 hours to work on their game. The theme of the jam is released 1 hour before the jam officially starts, and everyone is encouraged to use this time for brainstorming ideas.

Submission Info:
A link to source is required when submitting. (open source is good for the soul, man.)
A link to a playable version of the game for either Windows, Mac, or Linux is required when submitting. This must include the executable and all assets/extras needed to run the game.
Games with NSFW or shocking content must be marked as such.
You are allowed to submit as early as you want, but there is no reward for doing so.

Rules:
1. You can work on a team of two, or by yourself. Must be stated when submitting.
2. You only have 72 hours to create both the code and the audio/graphic assets of your project. Pre-made fonts are allowed.
3. Game must be based on the theme ,but how the theme is interpreted is up to you!
4. Any programming language may be used, as long as SFML(or one of its bindings) is used.
5. External libraries are allowed, but not SFML's competitors, such as GLFW, SDL, Allegro, etc. The use of OpenGL is allowed, however.
6. We encourage the use any of the code posted in https://github.com/SFML/SFML/wiki/Sources, you may bind it to your language of choice, as long as you give credit to the original author.
7. Porting to other OS's after the 72 hour mark is allowed and encouraged!