astearon wrote:I've also known about a language that looks promising. It is both compiled and jit capable and they are aiming towards a full stack language.

Perhaps it might help you: http://www.red-lang.org/p/about.html

excuse my sloppy typing..just woke up and remembered about red

astearon wrote:I've also known about a language that looks promising. It is both compiles ant jit capable and they are aiming towards a full stack language.

Perhaps it might help you: http://www.red-lang.org/p/about.html

Red/System v2 is a ways away, isn't it? Do you happen to know why it has a preprocessor?

astearon wrote:

astearon wrote:I've also known about a language that looks promising. It is both compiled and jit capable and they are aiming towards a full stack language.

Perhaps it might help you: http://www.red-lang.org/p/about.html

excuse my sloppy typing..just woke up and remembered about red

Wow, looks exceptionally ambitious indeed...I think I'll be a very happy programmer when this is finished (or even hits 1.0)...sadly does seem to be a ways away from maturity though. But man, I hope they pull it off

Hey Josh, it's great seeing you doing well!
I don't know if you have seen my comment on the KS update, so I just wanted to somewhat repost it here.
So when I was reading your OP about how you where having an hard time finding a balance between ease of coding and performance, it reminded me a language/toolkit I used when Flash died: https://haxe.org/. This a platform initially aimed at creating cross-platform Games created by fine engineers. The most interesting part for you should be that this high-level & dynamic language can be compiled to C++ with great performance. You can also try other targets like the recent hashlink VM or Neko but I think it will be slower than binary code from Haxe/C++. Maybe this can help you tackle the FPLT.
Hope you and LT all the best!

Akryum wrote:I was reading your OP about how you where having an hard time finding a balance between ease of coding and performance, it reminded me a language/toolkit I used when Flash died: https://haxe.org/. This a platform initially aimed at creating cross-platform Games created by fine engineers. The most interesting part for you should be that this high-level & dynamic language can be compiled to C++ with great performance.

Haxe has great portability and toolkits, but the language basically copies Java/C# and the C++ target has all the overhead of a VM.

I just did some tests (simple numbers list and loops) and haxe C++ and nodejs are targets about two times slower than LuaJIT, but 5 times faster than hand-written nodejs and 50 times faster than Lua.

As much as you've tried figuring out these things on your own or with other resources, it does seem like you've gotten a few good ideas from people on the forums that might help you out. So I dunno, letting us know about your mundane problems sooner might be a good way to get help.

Thanks for sharing! I hope you're able to tackle the problem.

EDIT: and a long post like that isn't as visually appealing as the old videos you made, but I do enjoy the gritty detail of it, and find it mentally more stimulating.

All very interesting. Not a frequent poster (often too busy with my own projects) but yes I remember that kind of journey as a young developer leading projects.

Josh - you're certainly on the right track with breaking things apart into separate logical projects/assemblies; taking that further will be a great help to you. Write your components/classes as if they were third party APIs (which you would be happy to make use of). If they're hard to use and require a metric-tonne of scaffold/setup to use without falling apart then they're too complicated - it's time to refactor. if there are too many conceptual/logical inter-dependencies between components (A has to know not just what output B produces, but it has to know how B works) then it's too complicated - it's time to refactor.

Go and re-read the SOLID principles, then read them again, then have a sleep and afterwards read them again.

They are a huge part of the key to maintaining large codebases without driving yourself insane. Takes a lot of discipline but it's ends up marking a massive turning point in being able to develop and deliver these kinds of projects. You don't have to hold the whole structure of the app in memory, because whatever you're working on at the time does its job in isolation without needing to know anything about the rest of the project.

But the nicest design patterns can have a cost too: and that is, when the pretty structure, abstraction and workflow of the code create too much overhead and start to impact performance.
Especially in consumer software, where it is not an option to just upgrade the server hardware as in business backend software.

So even commonly suggested design patterns have to be evaluated according to their benefits (error avoidance and code manageability) and cost (performance impact).

Since Josh decided to return I might as well make a post too.
Based on what you've written it feels like the forums failed to really communicate this clearly enough but the people here tend to want the gritty reality of development and the unglamorous problems you face.

No, we communicated it well enough. I don't think Josh quite believed us until now.

Then you came back. Great! I do not understand programming, so I can not help much, but I understand people and it seems that you are trying to do something difficult - even for new technologies - to build a game whose idea is to exist in an infinite universe with ' Life itself, alone. Yes, it seems that most of your problems are right to exist or exist in the fact that you are alone. I find that terrible and you can change that.

With sincere consideration, from Brazil, your friend!

I am unsure if it has been used much for making games so far but maybe golang might be worth looking into? https://golang.org/ It has channels, can compile to most OSes and supports concurrency. It also appears to have a opengl library included in the standard library. https://godoc.org/golang.org/x/mobile/gl

SonarBeserk wrote:I am unsure if it has been used much for making games so far but maybe golang might be worth looking into? https://golang.org/ It has channels, can compile to most OSes and supports concurrency. It also appears to have a opengl library included in the standard library. https://godoc.org/golang.org/x/mobile/gl

If we're still throwing languages at Josh's face , Pony is probably faster.

SonarBeserk wrote:I am unsure if it has been used much for making games so far but maybe golang might be worth looking into? https://golang.org/ It has channels, can compile to most OSes and supports concurrency. It also appears to have a opengl library included in the standard library. https://godoc.org/golang.org/x/mobile/gl

It's one of the only major languages that I haven't given time to yet. I do need to check it out (although IIRC GC may be an issue here as well). Thanks for reminding me

0joshuaolson1 wrote:If we're still throwing languages at Josh's face , Pony is probably faster.

Yep, feel free to keep doing so! They're all going in a bookmark folder (and a Trello list) that I'll check out in the future. Thanks for this, adding it. Never know where you're going to find an invaluable codenugget