Jump to content

  • Log In with Google      Sign In   
  • Create Account

L. Spiro

Member Since 29 Oct 2003
Offline Last Active Today, 03:41 AM

#5301699 Scene System?

Posted by L. Spiro on 21 July 2016 - 02:08 AM

It's job is also to handle the transformation hierarchies of objects and the camera.

This is not the scene manager’s job; the scene graph is an implicit nature of the actors in the scene.
Actors themselves can be parents and children of other actors. Actors themselves manage how a parent transform affects their own transforms, etc.

The scene manager will issue a “pre-update” call to each actor, which actors can use to calculate their final transforms taking their local transforms with their parents’ transforms, but to the scene manager this call is a black box. The actors could use it to make spaghetti for all the scene manager cares.



In addition to what has already been said, I would point out that there is no reason to restrict yourself to having only a single scene at a time.
I real-life example that I had where 2 scenes would be the best solution was in a golf game I made in which you spend most of your time on the 3D field, but for swinging the club the golf course is shrunken to fit a certain area of the screen and a 3D guy swinging a club is overlaid on top of it with a different set of projections and view transforms.



Render-queues are a good way to sort objects for rendering inside a single scene, but if we are talking about overlaying the UI, debug text, etc., then you would really want layers.
Usually engines have a fixed and predefined set of layers, each intended to render a specific part of the scene.
Usually there are about 16 layers, but most of them are blank or “reserved” for future use.
An example of a simple set of layers would be:
Layer 0: Player.
Layer 3: Solid 3D objects.
Layer 5: Terrain.
Layer 7: Skybox.
Layer 8: Translucent 3D objects.
Layer 10: Post processing.
Layer 12: UI/HUD.
Layer 15: Debug text.


Layers are drawn in order, so later layers are drawn on top of earlier layers.
The way each layer is drawn is custom. The 3D layers would use render queues, but the terrain layer would use a system specific to terrain (chunks, GeoMipmaps, etc.), and the skybox layer would just be a single standard draw call.



  • Redrawing the entire scene from scratch is very slow
Too bad. That is what you do. If it is slow, it is probably because you are using glBegin() etc., and are otherwise non-optimal.
The solution isn’t to try redrawing only what has changed, the solution is to fix the actual bottlenecks.

The idea is that the scene system would accept requests to have things drawn, either once (during the next frame), or until the drawn object's lifetime runs out (i.e. next N frames).

Issue calls on a per-frame basis. Never assume anything about any future Nth frame. You don’t know when the player is going to hit the button to go to the next stage and all your assets need to be unloaded or exchanged.


L. Spiro


#5286341 programming language for android.....

Posted by L. Spiro on 11 April 2016 - 12:41 PM

I can't decide if i will study native language like Obj-C and C++ because I'm worried that maybe this language will no longer exist in the next decade.

Actually your thinking is backwards.
C++ has possibly been around longer than you have been alive (as for me it is only 1 year younger) and will be here long after you are dead.
If you are planning on programming in 10 years, you should be focusing on C++, as it is the only language guaranteed to be here a decade from now.

 

 

L. Spiro




#5286241 programming language for android.....

Posted by L. Spiro on 11 April 2016 - 01:15 AM

C++, if you want the pain. C++ if used correctly will give you more performance and control over the chosen platform at the cost of more developer responsibility. You will also be more tied to hardware as you compile for target type of CPU, this can be a bad thing in the fast moving world of mobile.

C++ doesn’t tie you to hardware. C++ is more portable than Java in the fast-moving world of mobile, as it is the only language supported on Android, iOS, and Windows Phone.
Moving portable C++ code to a new platform means changing the target architecture. Only.
All languages have API-specific functions that would need to be replaced when moving to a new platform, and this is unrelated to the language itself.


Your choices should be between Java and C++ (with the NDK), but these were mostly outlined above.
Debugger support for the NDK has been traditionally poor.


L. Spiro


#5286237 Proper Component Decoupling

Posted by L. Spiro on 11 April 2016 - 12:50 AM

Is it appropriate to have the collision detection code in a mover component given that the player is moving in response to the collision?

Absolutely not. Throwing in the note about it being a player that is moving in response to the collision is a straw man.
#1: It’s not even a valid framing of the situation. If the player bumps a tire, the player bounces back and the tire bounces forward. Is the player moving in response to the tire, or is the tire moving in response to the player?
Collision must be handled by something that doesn’t have a frame of reference.  They bounce off each other.
 
#2: What about when a monster hits a wall?  Or a car hits a monster?  Or a rock hits a car into a monster into a wall?
Are you going to duplicate your collision code for every case?  Clearly collision and physics don’t belong inside an update meant for a specific type of entity.
 

Also, this would require the component to have knowledge about objects it could collide with and where the screen edges are.

Correct, which is another clue as to why this is not the way to go. “God” has knowledge regarding all the objects in the scene, the walls, and how they should interact. The player is one of “God’s” puppets.
The player knows about itself, and some higher-level part of the game engine knows about all objects and how they interact.


The way it should be:
#1: A high-level system reads input and applies them to the correct player. For most games this means applying a force vector on the player, but for ultra-simple games it could mean an actual change to the character’s position.
#2 Normal: For normal games that use force vectors, a high-level run over objects is done to perform collision detection and physics. This results in a new set of force vectors which have been created to keep the player out of walls. This is also where item pick-up would occur.
#2 Simple: For ultra-simple games that modify the position directly, a high-level collision-detection routine is run over all objects (this could be done in the ECS fashion) and objects are sanitized (moved out of walls) and items are gotten, bullets hit enemies, etc.
#3 Normal: For normal games that use force vectors, an ECS-style run over the objects would be implemented to update their positions based on their force vectors.
 
Strictly adhering to the ECS fashion of running over objects and doing some kind of update on each component will lead you to extremely poor design.
ECS itself isn’t generally the best way to go anyway, and when you do go that way you still have to think about what makes sense as a per-entity update via some updating function going over each entity in turn vs. a normal update where objects are collected via some specific method and parts of them updated there.
Even if you are using ECS you still need to handle collision/physics in the normal way of gathering the minimal set of potential colliders (usually through a spatial partitioning scheme) and handling only them.
Even if your game is as simple as Pong it doesn’t make sense to run over every entity to handle collisions. It still has to be done at a higher level where knowledge of the game rules, objects, and boundaries exists.


L. Spiro


#5285898 A list of topics you need to know to have learned the basics?

Posted by L. Spiro on 08 April 2016 - 02:37 PM

How to use a debugger.


L. Spiro


#5285874 Creating an infinite grid in OpenGL 2.1

Posted by L. Spiro on 08 April 2016 - 12:49 PM

So factor is some number, canvasWidth is some number, and coordinateFactorWidth is some number divided by some other number.
The running theme here is that you keep not providing enough information for anyone to do anything but ask for more information.
Would it be so hard to provide the equation, and then say, “factor is 10, canvasWidth is 800”?
 
Did you try ::glLoadIdentity() as you were told to do?  If you are calling render() before drawGrid() it is fairly likely that the matrices are set to something strange.
Did you disable depth testing?
Are the dots a different color from the clear/background color?
Are the dots too close to the camera and being culled?  Why not push the dots back a unit?
How big are the dots?  Are you sure they are at least a pixel large?
Is coordinateFactorWidth an integer?  Is it rounding down to 0?
Did you set an orthographic projection matrix?
The first thing geometryEditorCanvas::drawGrid() should be doing is setting the model and view matrices to identity and setting an orthographic projection matrix.
 

glColor3d(0.0d, 0.0d, 0.0d);

This is not valid code. 0.0d = compiler error. If you want to type a constant double literal, use 0.0.
This suggests very clearly that this is not your actual code.
If you want help, post your exact actual code.
 
 
L. Spiro




#5285714 Keyboard input Windows

Posted by L. Spiro on 07 April 2016 - 10:28 PM

It was requested that you show your message pump, because most likely you're only handling one message and then running your game loop.
You need to handle all messages that are pending and then run your game loop.

Or you need to not clear your list internally every frame.


L. Spiro


#5285289 Is it bad to use macros such as __LINE__ or __DATE__?

Posted by L. Spiro on 05 April 2016 - 11:19 AM

For example, you might expect __FILE__ inside a header to show the header's name. That's "intuitive", but it's not what you get. It shows the name of the translation unit.

__FILE__ prints the file name last set by a #line directive.
#line is implicitly set before and after each file as they are #include’d and once at the top of the translation unit.
Unless you override the preprocessor’s internal file name and line counter with #line, __FILE__ prints the correct name of the current file, even if it is inside headers.
 

__LINE__ is the presumed (whatever that means) line number in the current source file. What's __LINE__ if you use it in an included header? You tell me?

The “presumed” line is the line the preprocessor counter tracks as if goes through the file, which will be accurate in any file as long as you don’t mess with it manually via #line.


L. Spiro




#5284877 Gamestate and Intro, Main Menu, Playing state

Posted by L. Spiro on 03 April 2016 - 10:51 AM

Sorry, by this I mean my game::run() loop, which looks like this (it is based on the game engine of Charles Kellys programming2dgames book:

Then I suggest we put that book aside.
There does not exist a case in which it is remotely acceptable to return from the main loop without having drawn the scene.
I said the main game loop allows you to update 0 or more times and always draws once.
You may possibly enter into a 0-length loop for updating if not-enough time has passed for a logical update, but you cannot ever under any circumcisions leave the routine without a single render.
And this is without even mentioning the Sleep()’ing sin. We don’t do that. No.
 

My bad, I am [still doing weird things].

I wave my hand and erase from your mind the concept of ECS and now you have become a better programmer.
What you mean to say is, “I have studied how structures of arrays gave me the same performance as ECS, and how an adjustment to my quad-tree such that all the leaf-node children are sequential inside a pool of memory took care of caches misses, and have decided that learning ECS and considering myself happy with the results cheats me out of learning how to solve actual performance problems and teaches me that over-reaching solutions are always best.  I will always be an inferior programmer and lose many job opportunities due to my inability to answer simple questions during interviews based on simple cache usage and understandings of basic programming principles.”

 

 

L. Spiro




#5284049 Actor object understanding

Posted by L. Spiro on 29 March 2016 - 07:44 AM

An actor is the base class for all objects in your game world.

It contains a world and local transform (position, rotation, and scale), and a parent and children actors for the scene hierarchy.

 

The end.

 

 

L. Spiro




#5284037 Gamestate and Intro, Main Menu, Playing state

Posted by L. Spiro on 29 March 2016 - 06:32 AM

General Game/Engine Structure
Passing Data Between Game States




When should they get loaded / rendered?

Loaded on the next frame after being set.
Rendered every frame.
 

Should there be a specific system for them (MenuSystem)?

What does that mean?
 

Do they need to be updated in the game::update() loop, or just the game::render() loop?

These are not separate loops. There is only 1 game loop, which may update the game logic 0 or more times, and always renders one time.
Fixed-Time-Step Implementation
 

I am working with what will hopefully be a component based engine .

Why would you hope for an over-engineered misguided system that you can’t possibly use correctly/fully and doesn’t serve your needs best?

ECS is a buzzword and solves a specific domain of problems suitable only to marketed engines such as Unity.  It’s not for you and doesn’t help you in any way.  Stop doing things just because they are buzzwords.


L. Spiro




#5283986 Making my game code cleaner/easier to work with

Posted by L. Spiro on 28 March 2016 - 09:36 PM

http://lspiroengine.com/?p=126
Read the “Structure” section.

It wouldn’t hurt to make your code readable. Use whitespace and several other coding practices to improve readability.

Sloppy:

private:
	sf::RenderWindow GameWindow;
	sf::Event event;
	sf::View GameView;
	int ScreenHeight;
	int ScreenWidth;
	int Section;
	char *GameTitle;
	bool Running;
	sf::Sprite PlayerLocation;
	MainMenu Menu;
	CharacterCreator CCreate;
	Map GameMap;
	Player Character;
	NPC TestNPC;
	Location MapLocation;
public:
	GameEngine(void);
	~GameEngine(void);
	void Start();
	void Loop();
	void Event(State GState);
	void MapSelection();


Readable:

private:
	sf::RenderWindow 	GameWindow;
	sf::Event 		event;
	sf::View 		GameView;
	int 			ScreenHeight;
	int 			ScreenWidth;
	int 			Section;
	char *			GameTitle;
	bool 			Running;
	sf::Sprite 		PlayerLocation;
	MainMenu 		Menu;
	CharacterCreator 	CCreate;
	Map 			GameMap;
	Player 			Character;
	NPC 			TestNPC;
	Location 		MapLocation;
public:
	GameEngine(void);	// Your choice to indent these.
	~GameEngine(void);
	void 			Start();
	void 			Loop();
	void			Event(State GState);
	void			MapSelection();


Incorrect:

private:
	…
public:
	…

Correct:

public:
	…
private:
	…


Etc.


L. Spiro


#5283920 Unreal 4 toon graphics redundant?

Posted by L. Spiro on 28 March 2016 - 02:50 PM

Cel shading is not a post-processing effect.
Research how it is implemented and then replace the rendering shaders with yours.


L. Spiro


#5283917 How much Maths/Physics do I have to know?

Posted by L. Spiro on 28 March 2016 - 02:38 PM

I don't feel it's very useful to list random things that you may need some day without context. For me, having context was important for me to learn it, and that means having a reason to learn it, which means learning it when I actually needed it.

Blindly picking a bunch of topics without having any specific application for them and trying just to memorize how I'm supposed to use them in the future would never have gotten me anywhere.


L. Spiro


#5283663 What do I need to know?

Posted by L. Spiro on 26 March 2016 - 09:45 PM

As implied above, this is a case of, "If you have to ask then you are not ready."

Knowing how to make an online game is the natural result of making many other types of games first and gaining experience. Going to a forum, getting advice, and trying to learn it all at once based on that advice is no replacement for experience.

You'll know when you have enough experience because you won't be asking how to make online games. If it is remotely possible for you to do it, you will already know how to do it. Or have a good understanding with only a few knowledge gaps to fill. Not having no clue how to begin.

Start with other smaller games and grow naturally. Fake growth at an unnatural pace only hurts you.


L. Spiro




PARTNERS