Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

WTF was that?

Bad Sector

Arcane
Patron
Joined
Mar 25, 2012
Messages
2,223
Insert Title Here RPG Wokedex Codex Year of the Donut Codex+ Now Streaming! Steve gets a Kidney but I don't even get a tag.
The reason I mentioned Casey is his compression method, which is as natural and simple as it gets.

Perhaps, but TBH i do not really like those talking head videos, i'd rather have a written article or some proper presentation. In any case, i have my own way of working which is fine for me.
 
Self-Ejected

Davaris

Self-Ejected
Developer
Joined
Mar 7, 2005
Messages
6,547
Location
Idiocracy
The reason I mentioned Casey is his compression method, which is as natural and simple as it gets.

Perhaps, but TBH i do not really like those talking head videos, i'd rather have a written article or some proper presentation. In any case, i have my own way of working which is fine for me.

I like a video if I can see it work. Watching Casey hammer out code easily and then one day he notices a commonality and he zips it down to almost nothing was impressive. Seeing something working is all the convincing I need.

If you are happy with what you are using thats great. But if someone quit progamming because of OOP, they should take a look at the links I posted.

For those folks, outside of his series this is the first of the articles where he first starts writing about COP in his The Witness series. I think there are 4 or 5 in total. You just click next to see them all. But really its just about returning to how people naturally programmed, before the OOP crowd appeared and made everything harder than it should be.

https://caseymuratori.com/blog_0015

https://www.youtube.com/watch?v=qWJpI2adCcs


Two for one. Mike Acton and HandMade guy.

I watched that. Its the first interview I have seen where a guest wouldn't let the interviewer ask questions, because he already had his own questions. lol
 

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,289
You just click next to see them all. But really its just about returning to how people naturally programmed, before the OOP crowd appeared and made everything harder than it should be.

I haven't really read this thread closely so I don't know what is the context, but the idea of OOP is make things easier... in large scale programs. I think games mostly are not that large scale and creating a class hierarchy for a game can be more work than you need. Besides I feel that the way some (most?) programmers think about OOP is just wrong. I was that guy myself, I thought I was programming in OOP, but it was more like "code stuffed in random classes" style. You can make it work, but if you aren't using inheritance for everything you possibly can, it's not proper OOP.
 
Self-Ejected

Davaris

Self-Ejected
Developer
Joined
Mar 7, 2005
Messages
6,547
Location
Idiocracy
You just click next to see them all. But really its just about returning to how people naturally programmed, before the OOP crowd appeared and made everything harder than it should be.

I haven't really read this thread closely so I don't know what is the context, but the idea of OOP is make things easier... in large scale programs. I think games mostly are not that large scale and creating a class hierarchy for a game can be more work than you need. Besides I feel that the way some (most?) programmers think about OOP is just wrong. I was that guy myself, I thought I was programming in OOP, but it was more like "code stuffed in random classes" style. You can make it work, but if you aren't using inheritance for everything you possibly can, it's not proper OOP.

Suggest you watch that Mike Acton video I posted and pay attention to the part about what happens when you get a cache miss.

It didn't make things simpler, thats why programming patterns books are so popular in OO. It didn't make software run faster, it made it slow and laggy, because it deliberately ignores how the machine works. It increased compile times in C++ to hours. History is about people talking about reality and people denying it.


 
Last edited:

redactir

Artist Formerly Known as Prosper
Joined
Jul 16, 2018
Messages
696
Not about Unreal but about a more astonishing limitation. OOP isn't the only thing with its issues.

One thing that caught me offguard is you cannot sensibly separate out a task into another function and depend on the compiler understanding when to just embed its code more directly anyhow.
Instead it will act as if there's no linear access being done simply because you hid some details behind a function call. This is not to do with a class member function in either case.

Someone here is probably aware of a special keyword or two that can achieve the result I was expecting.
But what this shows is you want as much of related code in one place as possible.
This also means that big-picture you can't just neatly tuck things into APIs (even if no OOP present) and hope for the best.

Cache misses aside, the right equation seems to be:

(WORK_DONE / (API_CALLS * LOOP_ITERATIONS)) = EFFICIENCY SCORE

Higher score means the more work you got done.

HOWEVER:
I would argue in cases where not much work needs to get done anyway, and looping is not that intense, then favoring a good API design and using it is actually preferable to worrying about the efficiency score.
Also in what I call the "I/O SHARING DEPTH", you must factor in that the results of WORK_DONE must be passed around your API. The frequency this occurs should cause concern.


(WORK_DONE / (DATA_PASSING_FREQUENCY * (API_CALLS * LOOP_ITERATIONS))) = EFFICIENCY SCORE

This modified formula is obviously nonsense because the DATA_PASSING_FREQUENCY is a triggering concern and also how much data is being passed must have bounds for us to care.


We can understand one iteration to mean just a single function call. One iteration of work is just work being done once of some kind.
Now we will rig our EFFICIENCY_SCORE to boost if our DATA_PASSED_PER_ITERATION is less than 1. However one what?
We'll call it U. And 1U means: max total data we should be passing overall and call ourselves good programmers.

Result:
(WORK_DONE / (API_CALLS * LOOP_ITERATIONS)) * (U / DATA_PASSED_PER_ITERATION) = EFFICIENCY SCORE


edit:
_____________________________________________________________________________________
DATA_PASSED_PER_ITERATION should probably better named AVG_DATA_PASSED_PER_ITERATION


(WORK_DONE / (API_CALLS * LOOP_ITERATIONS)) * (U / AVG_DATA_PASSED_PER_ITERATION) * ((LOOP_ITERATIONS * AVG_DATA_PASSED_PER_ITERATION) > U) = EFFICIENCY SCORE

In this case we rig the formula to say our efficiency is zero if we project we exceed our U from an " average sum". Thereby conflating our top ideal of data passing as mandatory cap. In b4 a mathematician tell me that's not necessarily implied.
 
Last edited:

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,289
I don't like to watch OOP criticism videos, because they are boring and those people don't know what they are talking about. You can make C++'s OOP quite fast, but just maybe it's a bit slower than when you write your custom C code for things like lists. I don't really see any single reason why OOP would be slow than bad programming of course. My OOP C++ projects compile fast and they are fast, there is nothing that would make them so slow that it becomes a problem.
 

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,289
One of the things I've noticed recently (well, I knew about this quite long ago, but didn't implement it that well) is the "traffic" through getters and setters. I think getters in particular are bad idea, because it breaks the way classes should work. You can't avoid getters but minimizing amount of them is one of the important things in OOP at least in C++. And I'm guessing this is one of the mistakes many programmers do when they are new to OOP.
 

redactir

Artist Formerly Known as Prosper
Joined
Jul 16, 2018
Messages
696
One of the things I've noticed recently (well, I knew about this quite long ago, but didn't implement it that well) is the "traffic" through getters and setters. I think getters in particular are bad idea, because it breaks the way classes should work. You can't avoid getters but minimizing amount of them is one of the important things in OOP at least in C++. And I'm guessing this is one of the mistakes many programmers do when they are new to OOP.

Except for basic data types, it's always better to get a reference or a pointer to an object. Unless the object fits into the same number of bytes as your pointers already use. (spoiler this means 4 bytes or 8 bytes max).
I consider pointer access to require no extra data if it's predictable for the object to have ownership of it (in b4 standard committee BS)
Anyway if you're already working with an object then the relative offset to its data members is more or less one instruction to process.
That said copying is copying which is why working with a reference or pointer should be preferred.

If your getter does like 5 checks and/or some legit calculations before returning the data member of the class, yeah that *might* mean there's too much cost to having the getter .

Knowing your target platform and userspace environment will tell you if your getter worries are retarded or not.
If you can have a robust and smart getter that prevents errors/confusion, it may be totally worth the price. That's rare though.

bonus vacuous truth: But we are hardly omniscient about our own programming designs and should becareful about comitting.
 

Punch

aaaaaa
Patron
Joined
Jan 1, 2018
Messages
132
Grab the Codex by the pussy
OOP is a legitimate helper and timesaver if you work at any project with more than 1 programmer assigned to it. There's a reason why MUH CORPORATE is so fixated on it, it leads to standardization and organization of code, you don't actually NEED it to be following OOP exactly but that's what most people know at the moment, it's not perfect but it's the best thing we have to prevent a team of programmers to fight each other 90% of the time instead of getting shit done. We have a pre-OOP project in where I work and unlike the other projects we mostly spend our time wrestling with it trying to get the simplest of shit to go through whatever autism the code has become.

Mind you, I'm talking about non performance/resource starving applications here, which is basically the bulk of programming projects and jobs. OOP in a single person project and/or performance critical application may or may not be retarded.
 

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,289
That said copying is copying which is why working with a reference or pointer should be preferred.

I was talking about different kind of getters, like those which return one variable inside the class etc. Using reference vs. value (copying) is another topic and obviously unneccessary copying is bad and possibly something you might do when you are not aware of it. But it's more like really beginner problem. Using getters (and setters) to change individual variable inside the class is more intermediate problem, when you need a fast solution.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom