Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Satharis

Member Since 18 Oct 2007
Offline Last Active Today, 01:17 AM

Posts I've Made

In Topic: Advice for simple 2D game

Yesterday, 12:44 PM

Ahh! ofcourse!
Pardon my confused brain.
Anyhow, i tried to install SFML on Visual Studio 13.
I know that the latest version of SFML isn't compatible with Visual 13.
So i tried using Cmake, everything went on smooth untill i stumbled upon this Error:
 
Error    1    error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup    C:\documents\visual studio 2013\Projects\sfml 2.0\sfml 2.0\MSVCRTD.lib(crtexew.obj)
Error    2    error LNK1120: 1 unresolved externals    C:\documents\visual studio 2013\Projects\sfml 2.0\Debug\sfml 2.0.exe
Im not sure what ive done wrong, might it be that ive included wrong library's?
I know i atleast included SFML_STATIC in the C++ Preprocessor that many seem to miss.

I would expect it to not work on a visual studio version that doesn't exist. If you meant 2013, well it is compatible.. they just don't have pre-built binaries for it, you have to do it yourself.

As for the error, your project settings under linker->system->subsytem are set to Windows, which means the linker is trying to find the WinMain entry point, I'm assuming you wrote a main function instead.

You can change the subsystem to console to solve that, that will make it spawn a console window and call main, all the SFML code will still work fine, it can still create a window and all that. Alternatively SFML comes with a little library you can add to the linker input called sfml-main.lib, all that really does is provide a winmain function that calls the standard main function, so just by adding it to the linker input you can use your standard main function even if the subsystem is set to Windows.

In Topic: SDL Pausing game help?

Yesterday, 12:26 PM

is paused already in the sdl library?

Most people think of pausing in the simple sense, it freezes the game, but in reality it never does. That may or may not be obvious, if you think about a game like the old Zelda games, pausing would take you to some kind of inventory screen. Obviously the game world was still paused in that case but many other elements of the screen had to still function.

Basically pausing doesn't simply halt the game, it halts the ingame logic. How you do that depends completely on the way you've structured your code, if you have your game calling some kind of tick function you probably want it to continue calling it, but maybe a layer under there where it is calling tick on the game objects like the AI, movement, etc, you would either designate some variable and basically stop updating them altogether if it was true, or you could just pass them a delta time of zero to get the same basic behavior.

A library is unlikely to have any kind of pause function unless it has some access to the game loop and actually "knows" where the logic is going to happen so it can stop calling updates on it.

In Topic: The "action" systems that 2D game frameworks all now have...

25 November 2014 - 03:10 PM

To be perfectly honest a lot of people don't understand how the more low level parts of a game engine like the game loop usually even work, my thoughts would be this whole action system thing developed as a way of hiding away all that code to make it simpler for a wide range of coders. You are talking about a framework for 2d games, not the deep down code of a massive engine like source or unreal or something. XNA hid its game loop as well if you used the base game class.

 

I haven't actually used any of these "action" things but taking a peek at cocos it seems like it would be pretty standard behavior you might implement in a game anyway, movements or color changes to sprites either instantly or over a period of time, based on the code it seems like a bit of a soft excuse for them to have hidden the core game code away in some singleton instance. At the very least they'll be tracking time and doing a bit of a mini-loop somewhere to actually advance all the actions and things anyway.

 

Is it good or bad? I don't know, I guess that's in the eye of the beholder, it probably makes things a lot more accessible in the same way that Unity has severely lowered the ceiling for coding ability that you need to throw together a game. Personally I'm more interested in down to the metal access and is the main reason I stick to libraries like SFML instead of frameworks that abstract everything away for you without any control. Why? Main reason is you learn a lot more, there are quite a lot of projects out there you might want to attempt someday, or working with others, that require someone to know all that down to the metal implementation information.

 

If you're going to USE cocos I would say you'd probably make your life a lot simpler to prefer their methods to what you're used to, unless that isn't -enough- to do what you want to do. I'm not that old really but to be frank I would say there is much more of a divide growing between code that would made by someone able to develop a full fledged engine for a game, and someone who does nothing but script for middleware.

 

Develop a game faster but have a much lower ceiling on your knowledge, or take much longer but have a greater depth of knowledge. Seems to be a wide divide these days.


In Topic: Proper C++ header file?

21 November 2014 - 11:25 PM

It's not portable because even though the compilers support it, there is no guarantee that they all function the same between compilers.

There's no guarentee of that basically anywhere in the C++ language, most of the standard is worded very vaguely and usually specifies only the minimum behavior that something has to do to be standards compliant. The only argument you even seem to be making here is that there isn't a standard definition of the basic things that pragma once must do(because it isn't a standard directive) even though it has shown to accomplish the same basic goal just fine across a variety of compilers.

In short you're basically saying we should avoid using it because it isn't standard, which is not a compelling reason IMO.


In Topic: Proper C++ header file?

21 November 2014 - 08:39 AM

The reason I brought it up was because we're in the "For Beginners" section, where we try to be as exact and correct as possible.

Which we are, the only thing I agree with so far is that yes, it is non-standard, it isn't specified in the standard.

There are also a lot of students reading this section, and students are often instructed to follow standards.

Okay.. that means following standards their teachers set them. What I'm writing is an application of good programming standards, not commonly followed standards. I certainly wouldn't recommend everyone go around throwing macros in everything just because a student comes in here with their teacher having asked for some giant macro horror page for their next assignment.

If we want to talk about common, pragma once is probably one of the most common non-standardized preprocessor directives.

For them, using non-standard pragmas could cost marks.

Or it might not, depends on the teacher, which is why they are being taught right now that pragma once is a useful tool and you should prefer to use it if you can, not to always default to #ifndef header guards because they might be more pragmatically correct to a teacher. Not everyone here is a student.

I certainly appreciate the point you're trying to make, but I'm also trying to make one that we shouldn't just go "Okay, everyone do it the old fashioned way."

PARTNERS