Advertisement

running flat, feeling burnt out...

Started by April 11, 2014 07:52 AM
10 comments, last by cr88192 10 years, 5 months ago

To be honest BGB, since I noticed your posts, I have had many doubts about your ability to focus and I'm somewhat disappointed to have been proven right.

Your motivation didn't go away. You dissipated it. And you're still totally into the correct mindset to to this over and over. Just look at the nonsensical amount of irrelevant low-level detail you post even in this thread. I mean, just read this. Just read it.

like, while I could, for example, go and implement a newer scripting language and VM and maybe fix up some issues with my older one, this would be pretty solidly in "yeah, been there" territory, and the only real likely gain would be trying to make it more performance competitive with C, vs like 3x slower than C (in the JITted case), mostly because this slowdown largely keeps scripting code from being usable in performance-sensitive areas (such as in the renderer). (the planned scripting language would have been somewhat more C-like, vs my old one being at this point more of an AS3 clone).

Like anyone cares how fast/slow a game VM is. Epic had to go AAAAAA with their 3th engine iteration before seriously considering their internal VM slow. They are set up and sitting on hundreds of millions. Everyone using UnrealScript would tell you it was not suitable for performance, but it was suitable for its task.

My VM is not suitable for performance, but it is suitable for its task (1% frame time). It is orders of magnitude slower than C (like 1000x). Is it a problem? No. Will it be a problem in the future? Sure, if I end up having like 3/4 of worldwide engine licenses. I will be happy to scrap it.

rasterizer, basically written and tested, currently pulls 500-600 Mpix/sec for big/simple texture-mapped primitives, and around 800 for interpolated colors.
this was after fiddling with some of the arithmetic and similar.

but, it will require being fully implemented to see what the overall performance is like.

Here you go again.

I hope you realize the end users want you to speak their language, not yours.

If you wanted to do Quake+voxels, and your friends are on iOS games what did you expect they would tell you?

You need a higher level vision of what you need/want to do. Then you execute it. And never, ever assume your vision is going to be successful in the first place.

For the time being, just get off for a while and think at what you want to do to move forward. How can you transform what you have into value for your next step?

Previously "Krohm"

To be honest BGB, since I noticed your posts, I have had many doubts about your ability to focus and I'm somewhat disappointed to have been proven right.
Your motivation didn't go away. You dissipated it. And you're still totally into the correct mindset to to this over and over. Just look at the nonsensical amount of irrelevant low-level detail you post even in this thread. I mean, just read this. Just read it.


I don't really think any higher level than this.

I personally have never really been able to think particularly "high level".

it is roughly the same sort of thing as trying to "plan" things. it is a stressful and not-particularly-enjoyable experience.
usually easier to just do whatever, and deal with and evaluate things as they come up (like, acting in response to whatever is going on at the moment and similar), and then generally sort everything out after-the-fact.

not necessarily that a person should go and deliberately shoot themselves in the foot, like what does a person gain from screwing themselves over?...

though, I think I am at least a little better at designing and planning things than I am at trying to think high-level, as at least these mostly just boil down to "pick whichever parts have the most desirable properties, and if two options have seemingly equal weight, pick one at random...".


but, it is starts getting rather lame when there isn't really anything obvious that needs to be done, or things get overly open-ended, ...

luckily, at least with "clone stuff" tasks, it is a little more obvious which features are needed.

like, a person can just hammer away writing piles of code without needing to spend too much time/mental-energy/... on the whole "thinking" thing.

I think in my case, I may not have burnt out on anything particularly coding related, but more burning out on trying to spend too much mental energy thinking about stuff, trying to evaluate what is or is not useful, getting stuck with being expected to think about the future, ... vs, you know, doing stuff.

like, while I could, for example, go and implement a newer scripting language and VM and maybe fix up some issues with my older one, this would be pretty solidly in "yeah, been there" territory, and the only real likely gain would be trying to make it more performance competitive with C, vs like 3x slower than C (in the JITted case), mostly because this slowdown largely keeps scripting code from being usable in performance-sensitive areas (such as in the renderer). (the planned scripting language would have been somewhat more C-like, vs my old one being at this point more of an AS3 clone).

Like anyone cares how fast/slow a game VM is. Epic had to go AAAAAA with their 3th engine iteration before seriously considering their internal VM slow. They are set up and sitting on hundreds of millions. Everyone using UnrealScript would tell you it was not suitable for performance, but it was suitable for its task.

My VM is not suitable for performance, but it is suitable for its task (1% frame time). It is orders of magnitude slower than C (like 1000x). Is it a problem? No. Will it be a problem in the future? Sure, if I end up having like 3/4 of worldwide engine licenses. I will be happy to scrap it.


it would mostly matter where it is used.

as-is, script code can be used mostly for game-logic and scene-graph and UI related tasks (or, things like animation control or effects), ...

but, it can't really be used for dealing with lots of raw vertex or pixel data, most of this stuff needs to be left to C (and even there, some attention needs to be paid to performance issues).

so, there was some on/off desire for an ability to have script-code be C-competitive for things like dealing with vertex-data and raw image/video data, while still being able to load it dynamically from source form or build code fragments at run-time.

but, it hasn't really been in-general worth the levels of infrastructural pain it would require to try to squeeze out that last 3-5x.

rasterizer, basically written and tested, currently pulls 500-600 Mpix/sec for big/simple texture-mapped primitives, and around 800 for interpolated colors.
this was after fiddling with some of the arithmetic and similar.

but, it will require being fully implemented to see what the overall performance is like.

Here you go again.
I hope you realize the end users want you to speak their language, not yours.
If you wanted to do Quake+voxels, and your friends are on iOS games what did you expect they would tell you?

You need a higher level vision of what you need/want to do. Then you execute it. And never, ever assume your vision is going to be successful in the first place.
For the time being, just get off for a while and think at what you want to do to move forward. How can you transform what you have into value for your next step?

I liked Quake, and liked Minecraft, so this was the motivation.

I was also well versed in how the Quake family engines worked.

personally, I never really liked either CIV or things like Candy Crush or similar. don't really get it...

and, otherwise, taking a break off in "implementing whatever" territory, I have ended up with a now more-or-less working software-renderer OpenGL implementation... beyond this?... no idea...

This topic is closed to new replies.

Advertisement