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 - MorleyDev

Pages: 1 2 [3] 4 5 ... 15
31
General discussions / Re: SFMLEasy - Compile the lib quickly
« on: July 21, 2014, 03:37:26 pm »
It's possible java launching another program that your antivirus is having issue with. Or that it simply is false-alarming something cmake does. Anti-viruses and development tools tend not to get along, so personally I just do all development in one folder and have my Anti-Virus set to disable looking in my development folder. Perhaps not the safest of options, but since otherwise every antivirus I've found eventually trips over something to do with compilation or running self-compiled programs...

As for this as a tool, well...for SFML alone it's two lines of cmake in the command line:
Code: [Select]
cmake ${SFML_DIR} -G "${GENERATOR}" -DCMAKE_BUILD_TYPE="${BUILD_MODE}" -DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}"
cmake --build . --config ${BUILD_MODE} --target install

More value would be in a generic tool that can support multiple libraries and compilers with caching and such, kinda like a NuGet for C++. I wrote the start of one for my university coursework, really need to pick it back up and get back to work on it (been a bit busy as of late with the job hunting and graduation from said university)...

32
General discussions / Re: Conditional C++11 Support
« on: July 06, 2014, 04:50:25 pm »
Yeah, I'm trying to avoid that (edited that post several times xD), but it's difficult to discuss the risks in both without mentioning the risk that it could be easier break something for only one compiler when supporting C++11. And that maybe at present there's not enough support for things like thread for a lot of the benefits people are talking about to actually be usable. In the future that may change.

So, essentially, the decision of conditional or unconditional to me seems to be based on how much of the kool-aid can we drink, or expect to drink? A light-weight touch could allow for unconditionalness (no move constructors or unique_ptr? 2008 called), but would make most of the benefits people talk about for going unconditional (std::thread, unicode literals) unusable without dropping support for various toolchains and it seems like most of those lightweight features are the easiest ones to make conditional.

33
General discussions / Re: Conditional C++11 Support
« on: July 06, 2014, 03:48:26 pm »
I'm just saying, it's still a more fractured a 'marketplace' than C++03 was.  If SFML allows C++11, then there is a need to declare which versions of the 'main' compilers/libraries to support. g++ 4.7? 4.8? 4.9? clang 3.3? clang 3.4? VC12? VC11? VC12 update? And there's a need to then not use features that break building on those compilers onwards.

For just not supporting C++11, this wasn't much of an issue since C++03 was well-established and fully implemented by the compilers. For C++11, it seems to me the complexity of ensuring support does increase. Now I'm still in favour of it, pros outweight cons, but I'd encourage appropriate steps taken to mitigate that complexity.

34
General discussions / Re: Conditional C++11 Support
« on: July 06, 2014, 02:52:56 pm »
I'd be all for SFML 3 being C++11 only. Way I see it, SFML 2.x is perfectly usable when targeting-C++11 compilers and since C++11 aids in writing code that is simple and fast, SFML 3 would benefit from it.

Though I know this not the place to discuss missing features, there are still issues with C++11 implementations that could cause problems with compatibility. I'd argue SFML 3 would need some type of build server setup, even if it's just Travis-CI and AppVeyor to cover clang, g++ and visual studio, just because otherwise at some point the build is more likely to be accidentally broken for one of the compilers if we enable C++11 support.

35
Bug or feature? Well, yes :P

Okay, so the actual explanation is that it is a mistake I made in the spritesheet. The actual 'tiles' are bigger than the visible walls, but some are off by a pixel and so look too far up or down or are missing some width, resulting in the jaggedness.

I decided the end result didn't really subtract graphically enough for me to be bothered with fixing it for a small prototype/university coursework. Which is why I'm not an artist or graphics designer, I guess :)

36
Ghost Hunt - Multiplayer Prototype
Download Link
Source Code (Git Repository)

Description
Written for university coursework, this is a multi-player game modeled after Pac-Man where the player and ghosts are all human players. The game is written in Scala using JSFML for graphics and audio. To run, download, unzip and launch either the ghosthunt shell script or the ghosthunt.bat batch file in the bin directory.

Controls
In-Game
- W = Move Up
- A = Move Left
- S = Move Right
- D = Move Down

In-Menu
- Mouse Click = Select a menu item (text boxes, buttons, etc.)
- Keyboard = Typing for Host and Port

Goals
The goals of the 'Hero' are to collect all the pellets and avoid the ghosts.
The goal of the ghosts are to hound and catch the player.

Known Issues
Gameplay
- It is possible for the ghosts to make victory impossible for the player by simply not moving, as this means they'll remain covering a pellet.
- It is difficult for the player to lose the ghosts when they are detected, as they have no means of repelling or escaping except for moving around the maze.
- Gameplay with only 2 players is boring.
- Players can't decide whether to be ghosts or the hero, the server automatically assigns those.
- Players can't start a game, the "Start Game" button is on the host window and must be clicked by whoever is running the host.

Technical
- If the hero disconnects, then two hero characters will be displayed on screen when the server returns to the lobby and in the next game.

Screenshots



Credits
FilenameTitleArtistLicenseSource
font.ttfSensationBernd MontagFreewarehttp://www.dafont.com/sansation.font
title.oggWingsHalcyonic Falcon Xhttp://creativecommons.org/publicdomain/zero/1.0/http://open.commonly.cc/
game.oggThose Of Us Who FightHalcyonic Falcon Xhttp://creativecommons.org/publicdomain/zero/1.0/http://open.commonly.cc/
endgame.oggThat Which We Have Lost And ForgottenHalcyonic Falcon Xhttp://creativecommons.org/publicdomain/zero/1.0/http://open.commonly.cc/
player_death.oggShot Gun Soundluminalacehttp://creativecommons.org/licenses/by/3.0/http://soundbible.com/1706-Shot-Gun.html
beep.oggbeepCHydranoshttp://creativecommons.org/publicdomain/zero/1.0/http://www.freesound.org/people/Hydranos/sounds/237706/




Hello, I figured I'd post this here. I made this casually in about a week fairly easily using Scala and JSFML, with the networking code going through Java sockets, for my coursework. Having now more-or-less graduated (still got to get the ceremony), I figured I'd share it around a little before it vanishes into the aether. I got an A for this, don't ask me how.

But I do like the core gameplay idea, so am toying with porting it over to something a bit more portable, making it less obvious a pacman clone, improving the assets (I made the graphics, the graphics suck), fixing the issues with the gameplay, implementing AI to allow for single-player or for game-play with 2 players to be enjoyable. I want to know if people think that's a good idea or not.

37
General discussions / Re: SFML 3 - What is your vision?
« on: June 25, 2014, 12:35:02 pm »
Well UPnP support would be nice for Networking, but I'm not exactly holding my breath for it.

Though with the Android/iOS release, a simple cross-platform UPnP would be neat. Allow for things written in SFML that can detect other players on the WiFi like Minecraft Mobile does.

38
For my university project I actually looked at C++ dependency management. I concluded pretty early on that any kind of binary hosting-based dependency management system is impractical at best, impossible at worst. So I made a system that uses Git and CMake to acquire, compile and cache dependencies, then updates those compiled dependencies. So long as the compiler in use for MinGW/Unix Makefiles remains consistent, ease of install and binary compatibility are fixed. Though you update/change compilers, you do have to manually delete the cache atm.

So using this system, getting the latest SFML debug binaries is as simple as:
zander_client get sfml2 mingw debug

Which will, internally do a git clone or git pull of sfml to a source cache, then do a cmake build of sfml2, install the artefacts from that build into an artefact cache, and then copy those artefacts to the working directory. If artefacts are already in the cache and up-to-date, it just does the copy to the working directory. If they're in the working directory but out of date, they get replaced by the up-to-date artefacts. If they're in the working directory and up-to-date, nothing happens.

At the moment the tools are pretty simple, a client written in scala and a simple rest api written in node.js, but I was planning on posting them here after I add a few more features. Like support for tags and branches, and custom cmake flags (which means different branches, tags and flags will have to result in a different cached artefacts).

Also it requires the source to be open source, hosted in a git repository and buildable and installable via cmake. So baby steps xD

39
SFML game jam / Re: Game Submissions now open
« on: June 06, 2014, 04:32:27 pm »
If this was primarily a Java or C# jam, then expecting people to be able to build themselves may be less problematic. There are well-defined tools and processes that can do all the dependency management for you and any build tasks for those languages. Maven, Visual Studio + NuGet are common and easy to use.

But SFML is primarily a C++ library, used by C++ developers. Most games for the jam will most likely be written in C++, and C++ is a difficult language to build things for simply because building is more complicated. CMake, Configure/Make, Scons, Visual Studio, Custom scripts, Makefiles. There are a lot of different ways to build things and a lot of tools for a lot of compilers. Building can be a painful process. Providing a binary package seems like a courtesy if nothing else.

Now, as for platforms...well, that's interesting. Forcing people to build for all platforms seems wrong. But at the end of the day, if you don't provide a binary for a platform then the users of your platform won't be able to play your game which means less exposure and less votes and less publicity. Seems to defeat the point of submitting anything in the first place.

But the target platform maybe should still be the decision of the developer, just with that knowledge that less platforms = less players = less eyes = less opinions to act as a counterweight.

Week long things aren't jams. I've said it before and I still believe it. Jams are short, once you start reaching the 1 week - 2 week range it becomes too long to call a jam and instead just "another project".

I didn't partake of this jam because I had an exam on the Monday that got higher priority. Making it one week long would have made me partaking less likely.

40
SFML game jam / Re: 3rd SFML Game Jam soon!
« on: May 21, 2014, 09:21:20 pm »
Cool-sauce. I may take a part in this one. Been playing around with Scala and JSFML lately and they mesh pretty awesome in some ways, good for writing quick code and good for writing 'proper' code, though the "mandatory mutability" of sf::Sprite goes against the way Scala wants to do things a bit. Also need to write some pimp-my-library stuff for it and vectors first I guess...

Though I do have a test on the Monday....though that test is one on "programming languages, multi-threading and client/server" which are more or less my thing so doesn't need much revision at least :)

41
General discussions / Re: Unofficial Nightly Builds
« on: May 20, 2014, 02:58:51 pm »
Out of curiosity, your build scripts are you invoking make/msbuild directly? It's just I recently learnt a neat little part of cmake that you'd think would be highlighted as a major feature but almost nobody ever talks about or seems to use: --build, --target and --config.

My build scripts for most cmake-based C++ libraries nowadays just look like
cmake ../SFML -G"[Generator Here]" -DCMAKE_BUILD_TYPE=[Debug/Release] -DCMAKE_INSTALL_PREFIX=[SFML DIR]
cmake --build . --config [Debug/Release]
cmake --build . --config [Debug/Release] --target install

No more worrying about if it's make, mingw32-make, msbuild /p:Configuration=Nonsense. Just three lines that can be used for any compiler.

Much more re-usable. So much re-usable I wrote a dependency management tool for C++ for myself that uses these with git for version control. Got it working for a basic cmake install, with caching and automated updating, already :) Need to add custom cmake flags and tag/branch based versioning and it's more or less usable for the majority of cmake-based projects xD Versioning will be where the complexity lies, I'm guessing. May release it into the wild at some point :)

42
General discussions / Re: SFML 3 - What is your vision?
« on: May 05, 2014, 11:55:24 pm »
Lately I've found the more I avoid the exception approach, the more I dislike the exception approach, the more I start to think that if recovery is probably, exceptions aren't the correct way to go.

Error condition resolving seems to have several approaches:
* Return object and throw exception on error. Immutable, but causes exceptions to be handled in an "expected" code path. Dislike.
* Return error code and emit value as an out parameter. Requires mutability for out parameters. Dislike.
* Return nullable/falsable data and use some other error reporting. Difficult in multithreaded scenarios as whilst values are immutable the errors mutable, and requires all returns to be checked despite that need being non-obvious. Dislike.
* Returning an explicit type that contains error details when error occurs, and the value when success occurs.  Still requires the check, but that need is more explicit. So far, the best approach I've found for when failure is an expected code path.

So loading a texture could look more like:
Code: [Select]
sf::Result<sf::Texture> texture = sf::Texture::loadFromFile("file.png");
if (!texture)
   std::cerr << texture.err() << std::endl;
sf::Texture actualTexture = *texture;

But exceptions are a common way of handling this, and I've even argued for them before. It comes down to the implied preconditions of the function. If the precondition doesn't specify that the file exists, then the response should reflect that and the optional pattern is the correct choice in my mind. An implied pre-condition to loadFromFile is that the file exists, so an exception is the correct response to trying to load when the file does not exist.

43
SFML projects / Re: SFNUL
« on: April 30, 2014, 01:43:54 am »
It depends on the threading model used by the MinGW version I believe. If it's compiled to use the Win32 threading model, it does not support std::thread, whilst the Posix threading model uses winpthread to provide threading support.

44
General discussions / Re: sf::Shader -- API to set uniforms
« on: April 27, 2014, 11:54:40 pm »
Presumably a switch over to GLM would have to wait for SFML 3?

And if C++11 required is on the cards for SFML 3, most of the current SFML typedefs for integral types could be replaced with the cstdint definitions (std::uint32_t, std::uint16_t, std::int16_t etc.)

45
General discussions / Re: SFML 3 - What is your vision?
« on: April 25, 2014, 01:23:16 pm »
There is a little overhead in adding an own event queue. Just call window.pushEvent(myEvent) would be nice.

If SFML were to implement a more complex event system, it would be prescribing more details about how the consumers of SFML are to interact with it. Allowing generics to be pushed onto the system would require a callback system of some kind.

Lets say, you would like to close a window after some seconds, check for network after some time, save a game state on disk every hour and so on.

There are other C++ libraries that provide this functionality, and implementing it yourself is not difficult but details are quite dependent on your own current system. Whilst the OS does provide some timer behaviour SFML could hook this into, it seems like a 'Game Framework' feature, not an SFML feature, to me.

Pages: 1 2 [3] 4 5 ... 15
anything