Jump to content

  • Log In with Google      Sign In   
  • Create Account

L. Spiro

Member Since 29 Oct 2003
Offline Last Active Today, 10:01 AM

#5315364 Getting more curious and curious

Posted by on 15 October 2016 - 04:16 PM

Isnt that jack of all trade master of none thing?

I don’t even agree with the basic premise.  Why can’t you master all?  Exactly what preventative barrier exists?

These obnoxious little slogans such as, “Make games, not engines,” and, “Jack of all, master of none,” put us into a mindset that causes these little catch-phrases to be true.


If I want to be a programmer, does that mean I have to not be an artist?  My avatar is a pencil-and-paper drawing, details in my signature.

I also make my own music (details in signature).  After I skipped 4 years in science in school I decided to write my own physics engine, which lead me to create a graphics engine so that I could see the physics in motion, which lead me to being a senior graphics programmer at Square Enix on Final Fantasy XV, but my passion was always in AI, so after graduating from Stanford’s AI course I am currently focusing on AI in my career.


Could you imagine if I had said, before all of these academic ventures, “I am interested in a lot of things, so I should just dip into it and not get too deep”?

Yes, then I would just be a jack of all and a master of none.  What a pathetic self-defeating attitude to life.


Get out there and leave your footprint.  This world is not for testing, it is for mastering.  There is literally nothing stopping you except some kind of self-defeating attitude that tells you that you have to either master one, or basically explore all.  No.  You do all, you master all.  No excuses.



L. Spiro

#5315231 UML diagrams for video games

Posted by on 14 October 2016 - 11:38 AM

the "UML" is mandatory.

Lecture your teacher on how these are not used in the industry (see many posts above), and for very good and obvious reasons.

Within such a modular grouping of code, logical connections between related code need not have diagrams for them to be clear to the people who matter.

Trying to use UML to explain the entirety of an engine or game is note only a waste of resources but counter-productive as it is nothing more than clutter in a programmer’s already-scrambled brain.  If I am working on AI, why do I need to know the entire class hierarchy of the entire game, including the UI, renderer, etc.?  If I need knowledge on parts of another system, talking to people directly is most effective, and in-house Wiki’s (the standard in the industry) are more maintainable.


A scoped UML diagram is pointless since people not-only don’t think that way but programmers tend to know their own scope anyway.

A non-scoped UML diagram of an entire project causes detail to get lost in the clutter and serves only to overwhelm everyone.

In either case, it takes time and resources to keep these up-to-date and representative of the actual code-base.

UML promotes a strict  unchanging design that is incapable of adapting to new needs as they arise for 2 reasons:

#1: They make it a pain in the ass to implement any changes, since time has to be added to update the UML diagrams.

#2: One of the ideas behind UML is to design first and then code, which is an approach that implicitly lends itself to a set course that is hard to change.


Not only that, but my biggest gripe is that UML uses wrong symbols.  According to UML, an empty arrow from one class indicates that that class inherits from the class to which the arrow points.  This is wrong.

Diagram <------ ModelDiagram

UML says that ModelDiagram inherits from Diagram.  But the arrow points the wrong way.  According to the arrow, “ModelDiagram goes into Diagram,” when in fact it is the opposite—ModelDiagram comes from Diagram.

Diagram ------> ModelDiagram

This is how UML should look.




We have tried this in my first company and we dropped it for a reason.  It doesn’t work, it doesn’t easily convey what it is meant to convey, it is hard to scope properly, and it is easy to abuse into a cluttered mess.  It takes man-hours and costs companies money.



But if you have to do it, I have no suggestions.  Just know how futile it is.



L. Spiro

#5314959 texture still show line between vertices

Posted by on 13 October 2016 - 04:26 AM

If you are running the same points through the same modification you will get the same results.
This means your normals are slightly off between similar vertices. Fix this before starting to use indices. You wouldn’t be able to generate indices anyway if the vertices are slightly off anyway, and even if you did then you would just be masking the problem, not solving it.

Re-examine your method for calculating points, specifically in how to generate discrete normals for same points.

L. Spiro

#5314949 Running into some octree problem

Posted by on 13 October 2016 - 01:38 AM

Don’t ignore it. Ignoring obvious problems leads to at least half of the performance problems we have today.

Either move the origin of the octree as mentioned above or use a better method for the vertical component of the tree.
Octrees are typically not used due to memory constraints and because they are a poor match for the landscapes in most games (hence the problem you are having).

What is typically implemented is a quadtree for the X and Z planes and a stack of flat boxes for the Y (vertical). Dividing the world into vertical slices fits better with actual in-game landscapes and requires very little memory.

L. Spiro

#5314688 Fast Approximation to memcpy()

Posted by on 11 October 2016 - 10:03 AM

A coworker provided this extremely fast approximation.
void memcpy(void* dst, void*src, size_t size)
                if (size > 1 && dst != src)
                                *dst = *src;

                // The rest can’t be that important
L. Spiro

#5314657 Fast Approximation to memcpy()

Posted by on 11 October 2016 - 06:51 AM

After creating fast approximations for sin() and cos(), I found that one of the heaviest functions on a per-frame basis is std::memcpy() (and std::memset()).
This is bothersome, so I decided to work on a cheap approximation for these routines too.

Post your fastest, cheapest approximations to std::memcpy() here!

L. Spiro

#5314256 Getting more curious and curious

Posted by on 07 October 2016 - 08:34 AM



My interest is conflicting with my goal really. That's my I am more confuse


No it isn’t.

I started off writing games.
While writing games, I was always interested in “how this worked”.  So I made games while working on a miniature framework of my own, and sometimes did mundane tasks such as reimplementing strcpy() or anything I was inspired to do.  While also making games.
Eventually at my smaller company I was writing more and more low-level code while others took over the game-code side of things.
Then I joined tri-Ace where I worked exclusively on their in-house engine, followed by Square Enix where I worked on the Luminous Studio engine for Final Fantasy XV.  Followed by working on CryEngine.
But I have always been wondering “how this works,” and am currently interviewing at Apple to work on their Metal and OpenGL drivers.  Even more low-level than engines.
Not only has there never been a conflict, it is exactly the mentality that has propelled my career through to where it is now, 5 countries later.
You don’t just make one or the other.  You can always work on them together, either in a single project or separately.  I am working on my own engine now, while also working on a new version of MHS (disassembler, assembler, hex editor, very low-level, part of my discovery of how things work), an NES emulator (again, part of my low-level pursuit of how things work), and an actual game.  You drift fluidly from one thing to the next, not just give up one and go to the other.  Work on your game, and work on your own game engine.  Simple.
Never stop exploring and never “give in” to something less interesting just because there is some bat-shit crazy stigma about “making games, not engines”.
It is up to you what you make.  Just do what you want and keep your life interesting.  And maybe you will naturally fall into a lengthy career at big-name places doing the hardest funnest work for the highest salary.

L. Spiro

#5314251 develop mode

Posted by on 07 October 2016 - 07:37 AM

some shader should be compile real time, depend on the Macro that pass into shader, Macro will be different. I 'm not sure ..

That is why you play the game, log all the macro combinations you get, and cache those results for later.

L. Spiro

#5313407 When should I use int32_t rather than int

Posted by on 30 September 2016 - 12:54 PM


for( auto end= someVec. size(), i =end *0;i<	end; ++i) {
 if (!someVec[ i] .invalid () !=false ) {
Nailed it.

L. Spiro



I think this should be a part of your mandated coding guidelines (as per your other thread).


Already sent the e-mail to the committee.

I have a pretty good feeling about this style guideline.



L. Spiro

#5313374 When should I use int32_t rather than int

Posted by on 30 September 2016 - 07:17 AM

for( auto end= someVec. size(), i =end *0;i<	end; ++i) {
 if (!someVec[ i] .invalid () !=false ) {
Nailed it.

L. Spiro

#5313369 When should I use int32_t rather than int

Posted by on 30 September 2016 - 06:33 AM

Since we are off on “fun” tangents on for loops…

for ( auto i = (someVec.size() * 0); i < someVec.size(); ++i )

L. Spiro

#5313252 State Change Management in D3D11

Posted by on 29 September 2016 - 09:18 AM

State management isn’t as consequential as in OpenGL, but it still helps a bit or a lot depending on the state(s).
As mentioned above, set your states only when the draw call is issued. Otherwise it is easy to get redundant states even with your tracking method.

SetDepth( 1 );
SetDepth( 0 ); // Just called after every draw call so that one draw call's state does not leak into another.

SetDepth( 1 );

L. Spiro

#5313212 When should I use int32_t rather than int

Posted by on 29 September 2016 - 05:22 AM

I specify the size of my integers in all cases (including types that are 32-bit or 64-bit depending on the target platform) unless I am using an API (such as OpenGL) that specifies a regular type.

If I am writing code meant to be used with OpenGL and it requires that I pass an int, I use int for all code related to that need (or GLuint, GLenum, etc.)
Use whatever the API wants, otherwise specify type sizes.

In that same vein, if Win32 expects NULL, I pass NULL, otherwise I would be using nullptr in my own code.
If a Win32 function returns BOOL, I check for FALSE or TRUE, not false or true (as I would otherwise do).

for ( int i = 0; i < someVec.size(); ++i )
for ( size_t i = 0; i < someVec.size(); ++i )

L. Spiro

#5313017 the very best resources I found for game programming

Posted by on 28 September 2016 - 07:38 AM

I usually go to a site called www.gamedev.net for resources, help, etc. You should look into it.

L. Spiro

#5312898 Coding-Style Poll

Posted by on 27 September 2016 - 02:02 PM

Which one is the correct one? Whichever one we happen to be using on that project. The differences in utility of these things are inconsequential. Quantifiably so. If you're starting your own project, use whatever. If you're joining an existing project, use what's in place.

Almost nothing is in place.  That is what we are to define.


Although it is fine to see what styles each person here likes, this topic is about how you feel about being forced to go against your grain, and examples of what things you would hate to be forced to do (this applies to everyone posting here, as many have explained what they like to do but not how they would be bothered going against that).



L. Spiro