Messages

1

Graphics / Re: Best way to render, performance-wise

« on: October 03, 2013, 03:50:31 pm »

My bad, I was trying out the sf::Int(number) variables which I'm going to use for networking later... and forgot that Int8 is equal to a 8-bit signed integer.

The error was merely overflow, and is fixed now. VertexArray worked perfectly, so thanks again for the help!

2

Graphics / Re: Best way to render, performance-wise

« on: October 02, 2013, 10:38:26 am »

One more question regarding vertexarrays... Is it not possible for us to modify the size as we add more vertices to it?

This is the code I use to add a rectangular sprite (Basically I use this function to replace any draw(Sprite) function in the previous version). Every time I need to add the 'sprite', I increase the size of the vertexarray by 4 and inputted the details (position, texture coordinates). This, however, results in a heap corruption... So, are we supposed to immediately declare how many vertices we need (just like in the tutorial example)? Or is there a way to modify the vertices amount as you draw?

(Vertices is the name of the VertexArray)
(xstr, ystr, xlen and ylen are vectors of float denoting the sprite [id]'s texture rect.)
(Please ignore the whitespace errors)

        ////Adds a quad at position xpos, ypos with texturerect id
void VertexManager::AddQuad(float xpos, float ypos, int id){
        sf::Int8 now = Vertices.getVertexCount();
       
        Vertices.resize( now + 4 );
        sf::Vertex* Quad = &Vertices[now];
       
        Quad[0].position  = sf::Vector2f ( xpos                 , ypos  );
        Quad[1].position  = sf::Vector2f ( xpos + xlen[id] , ypos       );
        Quad[2].position  = sf::Vector2f ( xpos + xlen[id] , ypos       + ylen[id]      );
        Quad[3].position  = sf::Vector2f ( xpos                 , ypos  + ylen[id]      );
       
        Quad[0].texCoords = sf::Vector2f ( xstr[id]               ,ystr[id]                  );
        Quad[1].texCoords = sf::Vector2f ( xstr[id]+xlen[id] ,ystr[id]                  );
        Quad[2].texCoords = sf::Vector2f ( xstr[id]+xlen[id] ,ystr[id] + ylen[id]       );
        Quad[3].texCoords = sf::Vector2f ( xstr[id]               ,ystr[id] + ylen[id]  );
}

Thanks in advance!

3

Graphics / Re: Best way to render, performance-wise

« on: September 25, 2013, 11:58:20 am »

Thank you for the quick replies!

1) Draw several things with a single draw() call by using a VertexArray instead of a ton of sprites (ideal for things like tiled levels)   

This is probably the most promising thing I can do to improve the performance, so thanks for the info
The tutorial is quite confusing however. Based on what I read before, a VertexArray is used to create geometrical shapes, not to list a bunch of texture-sprites and draw them on one go (which, I believe, is what you're talking about above).

Then again, maybe I should re-read the tutorial.

2) Not really.  Again, moving the texture to the window afterward is just an extra draw() call that doesn't gain you anything.  I've never heard of rendertexture being somehow faster or slower than renderwindow.

I was actually talking about a rendertexture that don't have to be changed anymore over the course of the game. Say, there are 10*10 background tiles, but these tiles are going to be reused over and over again per loop. I think rendering all 100 to a rendertexture would be faster, since later on you'll only have to render the single rendertexture per loop. (Basically similar as how you said VertexArrays is used, and is probably what Laurent is said regarding rendertexture)

Again, @Ixrec and Laurent, thanks for the fast reply! 

4

Graphics / Best way to render, performance-wise

« on: September 25, 2013, 10:28:01 am »

Hello again SFML community!

I am currently developing a game project, and it has come to my attention that the performance is quite lacking, at least for me and some of my testers.

One of my biggest concerns is the rendering method I use. Performance-wise, what is the most efficient way of rendering sprites to the window?

Currently I am using a RenderWindow and its draw() function to draw sprites on it, then use display() at the end of every loop. Some post on the internet suggested using a RenderTexture first, however, and only extracting it to a Texture and drawing it to the Window in the end of the loop.

1. So which one of these are better, and if neither of them are, is there a faster way to render sprites?

2. Will maintaining a "background" RenderTexture (a texture that won't change and can be reused over and over again) give significant improvement than rendering ~100 sprites to the RenderWindow per loop?

3. Which process is actually the most expensive one anyway? The draw(), or the display() function?

4. On an unrelated (window-related) note, what does setVerticalSyncEnabled() do? Can it be used together with setFrameRateLimit()?

For reference, the target FPS is about 30. There are occasionally some lag during gameplay on my laptop, but considering how it can run skyrim pretty fine (at low specs though), I kinda doubt the code logic is the source of the problem. Or can you actually 'request' more performance priority from the machine?

Thanks!

5

General / Re: Implementing online play to a game

« on: September 23, 2013, 05:31:14 am »

These links explain all:

http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/
http://gafferongames.com/game-physics/
http://gafferongames.com/networking-for-game-programmers/

The articles are awesome, thanks!

1) Depends on the genre, but in most action-like games, you can just send player input, which is an absolutely tiny amount of data.  Though sending position/HP/etc wouldn't be a big jump either way.  How much data you send really doesn't matter that much unless the quantities are enormous; what really matters is the network latency, which you have no direct control over.  If latency were 0, you could easily have infinite frames.  It latency were abysmal, 30 fps would be impossible no matter what you do to the code.

2) Yes, it kinda has to be UDP.  The problem with TCP is that if a packet gets lost, it will take as long as necessary to successfully resend it.  In a multiplayer game, if a packet gets lost, then it's already worthless.  Newer input always trumps older input.  Thus TCP actively works against you.

The best will be both: UDP and TCP, tcp for important things like a message, a name, important commands...
and udp then for the position and all smooth stuff (where the specific order has no matter, just the speed).

However it is easier to deal with tcp, thats the reason I suggest making it tcp only, because it is good enough for what you are trying to do.

Since I believe the quantity is still small, I guess I'm going to try TCP first then (Though since this is a practice project I would try UDP too later on). But by "This happens if you send too much data, but in this "simple" game TCP is totally fine.", does this mean TCP data losses only happen if the data sent is enormous, or are you saying that minor data losses are negligible?

One more concern: What if I'm trying to connect more than 2 players?
TCP is said to be one-on-one, so does that mean I have to create a TCP connection connecting each pair of players (3 connections for 3 players, 6 connections for 4 players, etc), and if yes, how feasible is it? What about UDP, and how do they compare?

I guess I should try implementing 2-player feature first before adding anymore players, but I believe this should come to consideration.

Thanks for the answers!

6

General / Implementing online play to a game

« on: September 22, 2013, 10:00:27 am »

Hello again everybody!

As the title might imply, currently I'm thinking of implementing networking to my game Blastorium. However, having zero experience with networking, I need to ask a question or two...

(For those who are not familiar with the game I'm developing, It's a bomberman-esque game (meaning it's real-time). I figured this info would be necessary)

• At a target of 30FPS, How much and what kind of data can/should I send?
  Should have both player calculate the logics themselves and only send the commands used by another player (Risk of missing some packets and making both players lose sync)?
  Should I instead just send the important informations (Player position, HP, and weapon usage) and let each machine handle commands themselves?
  Both of the above?
  Or should I have one server who receives commands of client players, calculates logic and sends the important information (Position, HP, etc) in return?
  
  I still have zero idea on how much I can send/receive with a reasonable enough connection, so please help
  
  
• Which socket type?
  Reading the tutorial UDP seems to be a good idea here (speed), but any expert insight on this?
  
  
• How do I connect two separate players through the net?
  Do I have them each send their IP adresses to each other prior to play? Or host an online server which catalogues online IPs and matches up players with each other? If the latter is possible, how (What kind of online server do I need to use, etc)?
  
  

And as a disclaimer, I suck at am still learning C++, using competitive programming as a base. I understand the basics and algorithms like dijkstra or segment tree or something but still have zero idea on class inheritances and stuff. Thus, I'd like to apologize beforehand if some of these questions have trivial answers or you have troubles explaining something to me... But I'll do my best to learn.

Thanks in advance!

(I'm still unsure whether this belongs in general or networking subforum. I'm asking about implementing networking, but I feel like some of the questions refer more to general topics instead of the actual networking module)

7

SFML projects / Re: my network game

« on: September 22, 2013, 05:08:11 am »

Hahahahahah the sound effects are perfect

Awesome game!

8

General / Re: Help - Random heap corruptions.

« on: September 13, 2013, 04:10:04 pm »

Sorry for unnecessarily bumping this, but I believe I still need help regarding the heap corruptions.

Again, it still runs fine on my computer, and I'm having difficulty with finding machines that produces the error on exit/play. Even if I did fix it I'd like to know the cause, since fixing through random trial-and-error changes isn't really a good way to improve myself in the long run.

If it means anything, here are my major suspicions for bug causes:
-The main menu function being a separate function instead of a class (leading to weird memory problems with the texture). I'm planning to make it into another class anyway, but does this assumption has any chance of being true?
-Select.h (and future main menu.h, maybe) not contained in global.h.
-The RenderWindow being held by every class via shared_ptr(s) even though I could use it through global.h?
-Library/external requirements? Kind of unreasonable, but I don't think anyone in SFML has encountered the problem... leading me to believe the errors are due to a lack of required file(s) in some machines
-Plainly due to my horrible code which is probably buggy somewhere

Again, I could probably try them one-by-one myself, but I would really appreciate expert insight on the situation, for the previous replies has greatly helped me in improving myself. Thanks!

9

General / Re: Help - Random heap corruptions.

« on: September 12, 2013, 03:09:14 am »

Updated the repository, that should fix some of them (mainly return; exit(); and define constants)
I still suck at using const though. I can't figure out how to make them usable across multiple header files... They can generate errors if two consts over different files have the same name, but they don't work otherwise.

Oh, and

Arrays are bad, because:

• they don't provide index/iterator checks in debug mode
• they don't have value semantics (you cannot copy, assign, pass to or return from functions)
• they are not very typesafe, since they can be implicitly converted to a pointer
• they don't have size(), begin() or end() member functions

std::array fixes all these problems without any disadvantages. In particular, std::array is not slower than C arrays (in release mode).

Still working on it, thanks for the information!

Still wondering about the heap corruption thing though. It works fine with me with either builds, and

Have you made sure your not leaking memory?

If not you can use this:

//DEBUG CODE
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#define DEBUG_NEW new(_CLIENT_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif

int main()
{
        _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

This will allow you to see any leaked memory when you close the program

doesn't show anything, apparently.

I need to get another machine to test it out.

10

General / Re: Help - Random heap corruptions.

« on: September 11, 2013, 02:39:38 am »

Make sure you get rid of some very error-prone low-level techniques: Manual memory management,

Obliterated every single * pointers (i think) since they caused a bug earlier. Except the one in XML reads, those somehow lead to errors when I change it.

arrays, global variables

Should I replace every array with vector, and can I know the reason why array is unsafe or something? Thanks.
Global variables was everywhere in the non-recoded version (and so were problems). It should be clean now though

C functions like printf()

The only ones I use is at the start of terminal. Will obliterate once help screen is finished, thanks.

rule of three (it's rarely necessary).

Can you elaborate what this is? I'd like to avoid that too.
E:Nevermind

 
Your code is full of other questionable things, for example: #define for constants, return; at the end of void functions, declarations far from the initialization and usage, non-portable backslashes instead of slashes in paths, using namespace (especially in headers), exit() calls, assignments instead of constructor initializer lists, non-standard headers such as <string.h>, magic numbers everywhere, ...

When you care more about code quality, runtime errors like the one you mentioned will become very rare, and you can focus on actual logic bugs

Most of them (exit, return in end of void) resulted from me running out of ideas to fix the bug... But the rest does come from my poor coding habits. Will fix the rest soon, thanks!

I think slashes have been fixed thanks to texus, by the way.

Thanks for the tips!

11

General / Help - Random heap corruptions.

« on: September 10, 2013, 01:04:28 pm »

Hello SFML Community!
This question is a bit long, so I'll try to summarize it first as briefly as possible.

I'm having problem with my game project, Blastorium.

It runs finely on my machine, but will randomly stop working (went not responding) in other machines. I'm using Windows 7, but the errors show no consistency on OS or specs. The most likely cause is heap corruption, as I did suffer from it some time ago (but it was solved on my machine).

My project's github can be found here, but as a disclaimer, I am an extreme beginner in C++ with nothing much of a guide on coding a program, so the code you're going to see is downright horribly untidy and unstructured.

Since I suspect scanning through all the files won't be feasible for most of you, here's the pseudocode:

Files used:
-Main.cpp (main)
-Interface.cpp (runs functions such as transition screens and main menu screen)
-Select.h/cpp (class, runs the select screen, that is, the part where you select weapons/stage)
-Tilelist and Texturemanager.h/cpp (class, manages sprites/textures and rendering individual sprites)
-Globals.h/cpp (class, contains a shared_ptr<> of all the classes below as for global access)
-Engine.h/cpp (class, the main game loop runs here. Calls most of other classes below)
-Player, Level, Powerups, WeaponManager, WpnBomb/Mine/Rocket/Medi .cpp/h (classes, maintains the aspects of the game such as players/powerups/etc, and also runs their Logic() and Render() functions every loop)
Each class below Engine.cpp has their own tilemanager and texturemanager, meaning they load files themselves and handles their own logic and rendering. Engine.cpp only calls them

Every class with the exception of main menu GUI classes (SelectManager) and utility classes (TileList, TileManager) is handled by GlobalManager class.
The GlobalManager class contains a shared_ptr<> to each of those classes, and each is initialized immediately once the app was run. Later on in the game. Engine.h will fill each of those classes with the necessary information based on user inputs (Which map, which weapons, etc). This is re-done every game loop, e.g. from start to game over.

Pseudocode of what's happening when you run it

• Run Main.cpp
• Main.cpp initializes Engine class, SelectManager class (select screen) and GlobalManager class
• Main.cpp calls MainMenu function (not a class) from Interface.cpp
• MainMenu() draws all the gears and receive input, returning an int
• If it signals a play command, main menu runs the SelectScreen function from SelectManager
• SelectScreen function receives input and returns accordingly
• Main.cpp runs the Go function of the Engine class, initiating the game
• Engine.cpp initializes every other class for a game round (levels, player, weapons, etc)
• Each respective classes loads their own files
• In each game loop, Engine calls the Logic and Render function of each class
• If a player's HP reaches zero, Engine calls the FinishMatch function of Data class
• Data class prints numbers then returns
• Engine then calls the EndGameChoice function (not from a class), which receives user input
• -If it selects play again, engine refreshes every class and runs again
  -If it selects main menu, engine stops and the program returns to Main.cpp, to no.3 to be precise
  -If it selects exit then the game exits accordingly

Heap corruptions commonly happens when you close the game (The last step, when you press exit) but in rare cases, during the initialization of the game after select screen (step no.7-9)

Do note that in previous versions, there were no select or main screens (meaning the program skips steps no. 3 to 6) and the game runs just fine. Perhaps that holds some relevance.

Anything that might help would be appreciated. As of now, I still hold very little knowledge on good/bad programming habits, or tracing the source of these errors, and programming in general.

I know that my coding is horrible and that the problem most likely stems from an incorrect structure of the program itself, but I really need help with it.. Most tutorials on the internet only covers the basics of a single file and not how they are supposed to work together, and I'm out of ideas on how to fix the problem (especially since it runs fine on my machine, making debugging difficult).

Another question, though not as pressing, is performance. Is there a reason why my game still somewhat lags at 30FPS even on machines that runs 3d games just fine? I'm pretty sure my code is not that horrible (or maybe it is) to cause such drop in performance

Thanks in advance, and sorry if the question is too much or lacking information.

12

SFML projects / Re: Project Blastorium: a bomberman-esque game (Visual C++ Express & SFML)

« on: September 10, 2013, 12:33:47 pm »

Bump.

Updated as of 10-9-13, added medikit.

Currently facing performance issues however (Random heap corruptions for some reason. Doesn't happen in my machine, but some testers reported it and I don't find any consistency with their OSes/specs. If you have any idea what the problem might be, please help)

13

SFML projects / Re: Project Blastorium: a bomberman-esque game (Visual C++ Express & SFML)

« on: August 29, 2013, 07:08:51 am »

I want to say that I really like the menu
Nice graphics used from RPG Maker . I thik that the third weapon( the rocket) is too powerfull   

Why thanks!

Actually I feel that the rocket is the weakest one of the three, due to how hard it is to hit (Which is why I made sure that when it does, it brings a lot of pain )

maybe you need to invest some time to create and a multiplayer-lan game

Some hope that you will port it on Linux?

I do hope that one day it will be playable from multiple machines but currently it's still very far from my skill level, haha. I'll do my best until then!

On that note, to any of the testers: It seems that the game is currently suffering from memory leaks, causing random freezes post-game for some reason. It would be very appreciated if anyone can tell if the game's working fine, or tell me when and where it freezes. I'll try to fix it asap, thanks!

14

SFML projects / Re: Project Blastorium: a bomberman-esque game (Visual C++ Express & SFML)

« on: August 26, 2013, 01:25:25 pm »

Nice graphics, I need to try your game.
Maybe you need to update the first post.

Good point. The link's been updated already, but I guess a screenshot of the title screen should be on the opening post as well.

By the way, thanks!

15

SFML projects / Re: Project Blastorium: a bomberman-esque game (Visual C++ Express & SFML)

« on: August 25, 2013, 06:08:34 pm »

It's updated (well, it has been updated a few times before, but this is probably the most major one lately)! Now it has the main menu screen and the ever-so-important weapon select screen which finally allows me to implement more than 3 weapons. I forgot which version was the last one I posted here, so perhaps the new pause screen is a surprise for some of you as well.

Took me long enough due to university freshmen orientations and stuff so progress' been slow lately, but hope it doesn't disappoint


(not pictured: awesome animations)


http://vot1bear.blogspot.sg/2013/08/v121-beta-select-screens-and-stuff.html

Looks good to me! Keep up the good work.

I kind of like the use of the console. Two key presses and you're in the game; that's good. Right now it seems that you have to restart the application in order to play again, but this is still very impressive from my view. Good job, man.

I feel as though I've been inspired to do better. 

Thanks, but sorry this update kinda terminates the use and simplicity of terminal and its two-press-game system (in fact it'll probably take like 20 keys to enter the game now... sorry again ) but it's kinda vital for further development, so there's no helping it I guess

Anyway, thanks for all the support so far! And as always, feedback would be very appreciated!