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 ... 13 14 [15]
211
Graphics / SetOrigin changes draw position
« on: July 11, 2011, 05:50:42 pm »
I'm pretty sure that's the intended behaviour. The centre of the sprite is used for both translations and rotations.

212
Every game development forum needs this stickied:
Write Games Not Engines

Typically a game engine is what you get when you refactor code out of a game to use in another game. Eventually you get a flexible and reusable code base and tool base.

As for SFML's purpose in games: SFML provides Input, Windows, 2D Rendering, Audio and Networking without having to worry about the OS being compiled for.

213
General discussions / Centralized resource handling
« on: July 08, 2011, 04:51:45 pm »
Well I've sorta done it cheaply at the moment, Each content type has an operator()() function which returns a reference to the SFML object inside it. Not the cleanest way to do it...

I did consider diving inside SFML and fiddling, but decided against it.

Well if you try and get a pointer to an Audio resource, for example, but the key you pass is for an already loaded Image, it notices the GetType() value is not correct, logs an error, and returns a null resource.

214
General discussions / Centralized resource handling
« on: July 08, 2011, 05:36:34 am »
I based my current project's manager on XNA's ContentManager. I've found it simple enough to use easily and flexible enough.

They're still stored as reference counted pointers, but the actual content's memory is free'd when unload is called.

You can Unload individual or by bulk, and the actual loading is handled by a loader service (Services are stored in a typeid->service map in the Game class) created by the driver being used.

Presently I have two implementations of that loader:

One that uses it's own storage and the resulting objects are managed inside it and therefore not really unloaded when Unload is called unless the reference counting of Content managers that are in charge of it goes down to 0. This one isn't thread-safe, obviously.

One that doesn't store the content in itself, so fresh copies are loaded by each content manager.

I actually prefer the second one.

Resources all inherit from a base Resource class and some rtti magic is done to ensure they are used in the correct circumstances (basically in Windows I hash the typeid for faster comparisons, whilst in Linux I just do a flat pointer comparison).

215
SFML projects / Groogy's Game Engine
« on: July 01, 2011, 01:14:46 am »
If you have trouble coming up with names for a project, my tactic is to just keep clicking random on wikipedia until something catches my eye ^^ My latest project is called "Zander" xD

I've found rather easy to create a singleton pattern which decides at compile-time whether it is gamma or meyers, or something the user defines.

Anyway looks interesting ^^

216
General / General Game Programming Advice
« on: June 29, 2011, 12:50:08 am »
Write Games, Not Engines.

If you wish to develop for Android, it uses Java (or to be PC a derivative language very similar to Java in every way but as it doesn't provide the entire Java library it is definitely not Java at all except for being it in nearly every way).
http://developer.android.com/guide/index.html

The iOS (iPhone, iPad, iPod Touch) uses Objective-C.

The Windows Phone uses Silverlight (So can be written using almost any .NET language), and for games it's recommended you use XNA which means you also have the potential to support Xbox and PC.

You can compile code from other languages for the Android and iOS, but you need to create the bindings. For iOS create Objective-C bindings. For Android you use the NDK to make Java bindings. For Silverlight, whilst you can mix C#, VB, F# and so-on you can't use C++/CLI from what I know. You can still mix it with XNA but that limits you to just targeting the PC.

There are tool sets and "languages" created which you can actually compile to Android and iOS, and some even have Windows Phone and even HTML5 compilation as well.

SFML uses OpenGL and so the actual library won't travel over to any of these since even the ones that use OpenGL (iOS and Android) use the Embedded Systems version. So if you really wish to make something for Android, you have questions like if you want to limit yourself to just Android or all mobiles or android and pc or...

SFML, java2d, OpenGL ES, DirectX, Allegro, the graphical parts XNA...they are all at their core rendering APIs. None of them teach you anything about game development the others will not. It's making games that teaches you game development ^^

If just Android, stick to Java. The NDK is a pain in the arse to use and usually not worth it.

(Damnit I nerd sniped myself with that link to the android page and you posted before me xD)

217
Graphics / How do I display a variable?
« on: June 28, 2011, 09:26:23 pm »
The boost library provides a boost::lexical_cast function that implements this functionality.

Code: [Select]

#include <boost/lexical_cast.hpp>
#include <string>
#include <iostream>
     
int main()
{
     int ntest = 10;
     std::string test = boost::lexical_cast<std::string>(test);
     std::cout << test << std::endl;
     return 0;
}

218
General / Pac man game
« on: June 28, 2011, 09:17:24 pm »
A good rule of thumb is logic and rendering should be entirely separate in the code. Logic should never read from or write to the screen and Drawing should never write to anything but the screen.

If you're breaking this rule of thumb you're usually doing something wrong, writing debug code which most likely won't be enabled in the final product, or making some very low level optimisations to crank out which are probably not needed unless you're working on pre-1995 technology

So for Pac-Man, read from the array.

219
Feature requests / sf::Image -> sf::Texture, sf::Image
« on: June 28, 2011, 08:38:21 pm »
Quote from: "Laurent"

There's only thing that I still need to solve: from a sprite you can get its texture, but from the texture you won't be able to get the pixels anymore (there will only be a slow "download" from the graphics card, into a sf::Image), so I don't know how people will do for pixel perfect collision detection. They'll probably be forced to store the collision data themselves, but this is really annoying.


Even if not doing pixel-perfect they'll still need to be keeping track of the collision data anyway (rectangles, circles, ellipses and the like) so it does seem to me as a problem that exists largely on the users end of things anyway ^^

The only difference if doing pixel-perfect here is they need to keep track of the original image or an optimized version of it (such as a bit-field)...

Plus being able to drop the image from RAM but keeping the texture in VRAM is definitely a plus.

Pages: 1 ... 13 14 [15]
anything