Messages

1

SFML projects / Re: R-Type 2D shoot'em up (C++17)

« on: January 15, 2018, 05:36:47 am »

Vey nice GUI! It is simply awesome.

2

SFML projects / Re: Nero Game Engine

« on: November 27, 2017, 07:11:48 am »

That's cool.

I'm polishing a full featured 2D engine soon, with SFML as its base. I have 3 years in that development, i don't release it becuase i'm finishing university and i don't have a lot of time.

But i know it is hard, i can recognize the very good job you have done!

Keep going, i'll looking forward it.

3

SFML projects / Re: I need help to realize my ideas

« on: November 25, 2017, 07:31:35 am »

Hi Rodrigo, Welcome to the great SFML forum, it is good to hear that you finished your project.
First you will need to expose the ideas you already have in your head, and what are your expectatives with SFML, then we can add ideas an tell you good approaches to them.

If you like, you can contact me by PM, i also speak spanish.

4

SFML projects / Re: Nero Game Engine

« on: November 21, 2017, 08:31:35 pm »

Release of the source code in December

At this stage of development, I've implemented all the features that as been plan for the First release to be done. The Engine is still not ready to be used, but there is not much work left. I will begin the restructuration of the code in the next days. I may change some classes or methods name and change some implementations etc. The code will be on github in three or four weeks.

In the same time I will be developping my game prototype. I don't know how munch time it'll take but it's only when the prototype will be finished that the first release will be officially announced.

that's all, I wish you a good day  .

Take your time, you're making such a piece of technology!

5

Graphics / Re: Trying to create a graphics engine

« on: November 21, 2017, 08:26:48 pm »

Only to advice:

I, as creator of a 2D Game Engine (i will public release the engine when i have time) i recommend:

If you want to make a game, you have a lot of Game Engines out there, you don't need to create one.

If you want to make your own becuase others game engines does not convince you, or, you want to learn.
Before launching you to this world, it will be not only good to lear how to use SFML and basic C++.

A really good engine need to be done by:
- People that knows about graphics processing.
- People that knows about good C/C++.
- People willing to read and investigate a lot.
- People that have time that can invest on the development of the game engine.
- More than 1 people.

Why more than 1 people?
You don't need only to create the engine, you also need to:
- Test it (a lot).
- Try to make the API programmer friendly.
- Make a proper documentation.
- If it will be multi-platform no one people can deep learn Windows/OSX/Linux/Android/IOS so you'll need people involved particularly in each individual area.

But in your time develping the engine, you may never finish it, but you'll end up learning a lot of things.

Have luck and fun in adventure. 

6

Graphics / Re: Storing sprites in a container for better performance

« on: June 09, 2017, 07:49:57 am »

if I store created sprites in a container instead of creating

From the point of view of the compileer engine engineering and analying a real 2D game (Discarding the GPU)

On a real game you'll:
- Drawing a bunch of sprites
- Apply effects and transformations to them
- Have some kind of data-persistence

So at the end you'll end up using a container!!!

Ok, how about create new:

spriteVector[ index ] = sf::Sprite() ;
spriteVector[ index ].setPosition( x , y ) ;
spriteVector[ index ].setColor( color ) ;
 

or reuse:

spriteVector[ index ].setPosition( x , y ) ;
spriteVector[ index ].setColor( color ) ;
 

You may think is cheaper to reuse, but is not:

When you reuse, you need to reset states you're not using => You end up with more memory access, so x86_64 and ARM addressing modes to write on memory you must at least use a intermediate register, popullating all the registers with the mess of reseting the state of an sprite can force the compiler to use the stack memory, stacks slots often remains in cache, in theory is faster than random heap access, but still much slower than registers read/write.

Thats is without counting you're making it harder to debug.

Better solution:

When you'll be updating the sprite's properties linearly you can schedule them to take the best of your processor like:

sprites[ A ].setPosition( x , y ) ;
sprites[ B ].setScale( sx , sy ) ;
sprites[ C ].setRotation( rot ) ;
 

you can make a vector of RenderStates and draw them all together:

/*
  Where:
  1 -> sprites is an std::vector< sf::Sprite >
  2 -> renderStates is an  std::vector< sf::RenderStates >
  3 -> sprite.size() == renderStates.size() is true.
  4 -> sprites[ 3 ] use the render states stored in renderStates[ 3 ]  ;

  Hint: if the #3 is false you can use std::min() as the size count in the loop, and after the loop you put
  "compensation code" if necessary.

*/
for( int i = 0 ; i < sprites.size() ; ++i )
{
    window.draw( sprites[i] , renderStates[i] ) ;
}

 

Because internally you'll end up calling:

// taken from: RenderTarget.cpp
void RenderTarget::draw(const Vertex* vertices, std::size_t vertexCount,PrimitiveType type, const RenderStates& states);
 

You'll end up using likely all the data from both entities so the processor cache and pipeline is widely used, thus executing it faster.

7

General / Re: SFML engine

« on: March 29, 2017, 07:02:49 pm »

It doesn't sound like you want to write a program and use a library rather use an engine and control it with a script.

Maybe you'd want to consider something like the Unreal Engine...
Although, they've even moved away from their scriping language and now use C++...

not exactly ture, what I really want to write an engine fully-based on SFML, so I still want to write a program and use a library but in a generic way so that I can use it in my projects without going again in details of SFML ( i.e : increase the abstraction ) as well as integrating it with scripts to make some tasks easier like LUA ( although I didn't know really what is lua role and what it will make easy and what not.)

That what I wish reach and hope to find an entry point to this.

Thanks

If you're interested, i'm finishing of developing a SFML based engine, but the user do code in Lua only. if you need more details you can contact me for PM.

8

SFML development / Re: SFML concurrency vs C++ standard

« on: March 14, 2017, 06:11:47 am »

I think that in this case the Facade API by SFML doesn't bring any simplification to the client code and should not be kept in the library, as opposed to the aforementioned std::chrono vs sf::Clock/sf::Time.

+1. 

Nothing more to say.

9

General / Re: C++ Memory allocation versus memory PC

« on: February 22, 2017, 05:39:07 pm »

Ok, here in this attachement is all code. The events happen in the main.

Thanks for attatching, i'll try to test your code, but let me ask a question: Do you come from a Java or C# environment?

10

SFML development / Re: C++ standards

« on: February 22, 2017, 05:31:24 pm »

C++11, C++14, C++17?

I think C++11 would be the best option.
C++17 its too new, i think the new standard is more focused on Multithreading and Parallelization.
The most useful new library on C++17 (for SFML) would be FileSystem.

Code simplification: smart pointers, type inference, range-based for, delegating/inheriting constructors, nullptr, lambda expressions, std::function, std::tuple

All of those are good, but IMHO its better to let the user use smart pointers for its own and don't impose them.

[[deprecated]] attribute (C++14)

I think it is necessary.

11

General / Re: C++ Memory allocation versus memory PC

« on: February 22, 2017, 05:18:44 pm »

The code you just shown does not have the entire code. Only a part of it (a class to be more specific)

where are?

#include "BUTTON.h"
#include "LAYER.h"
#include "TEXTING.h"
 

12

SFML projects / Re: Remnants of Naezith is now on Greenlight!

« on: February 19, 2017, 06:41:14 pm »

Totally amazing and impressive, excelent job!

13

SFML projects / Re: Let There Be Light 2

« on: January 22, 2017, 03:31:19 am »

Hey, I'm having trouble getting this effect: I need occluders to cast shadows over other occluders like this:



I need the box on the bottom to be affected by the box on the top (meaning: be in the dark), like the player is.
In (1) player and grey box are visible and on (2) only the player is in the dark while the grey box isn't affected by the shadow of the big box.
Any idea on how to achieve this?

I was messing with this severals months ago, i couldn't reach a reliable way to solve this issue, but you can try the method "renderLightOverShape"

14

SFML projects / Re: Dynamic Lighting [UnNamed]

« on: January 07, 2017, 04:35:21 pm »

Excelent work, hope i could contribute to this project in the near future and integate it on my enigne too.

15

General / Re: Events in seperate thread

« on: January 01, 2017, 03:25:44 am »

I got a very good implementation of rendering in another thread with SFML few months ago.

I used std::atomic, and discovered that events MUST be handled in the main thread.
So you will need to draw in the new thread, i think this is because the SFML implementation on Windows.