Live data from Hacker News

Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

racenis.github.io

51–60 of 254 posts

Re: Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

#51
"Some might say "just get a better computer". This is why getting a better computer is bad:

1. Affordance: A lot of people, especially from 3rd world countries are very poor and can't afford to buy hardware to run Turbobloat.

2. e-Waste: Producing computer chips is very bad on the environment. If modern software wasn't Turbobloated you would buy new hardware only when the previous hardware broke and wasn't repairable.

3. Not putting up with Turbobloat: Why spend money on another computer if you already have one that works perfectly fine? Just because of someone else's turbobloat? You could buy 1000 cans of Dr. Pepper instead."

Took the words from my mouth. What a great project. Please keep posting your progress.

Re: Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

#52

I replayed Half-life 2 recently and was struck, even without high-res texture packs, how amazing the game still looks today.

That's why I think really good art direction beats raw graphical power any day. Source was pretty impressive back in the day, but the bit that's stood the test of time is just how carefully considered the environments and models are. Valve really put their resources into detailing and maximizing the mileage they got out of their technical constraints, and it still looks cohesive and well-designed 20 years later

Definitely. A hyper-talented team combining new physics-based gameplay, art style and rendering technology made something just amazing.

Re: Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

#54

I replayed Half-life 2 recently and was struck, even without high-res texture packs, how amazing the game still looks today.

I just replayed Half Life 2 less than a week ago! I also caught myself thinking, "the levels may not be as detail filled as modern games, but the artistic direction both in graphics and level design is better than many modern designers with bigger budgets."

Re: Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

#55

" Some might say "just get a better computer". This is why getting a better computer is bad: 1. Affordance: A lot of people, especially from 3rd world countries are very poor and can't afford to buy hardware to run Turbobloat. 2. e-Waste: Producing computer chips is very bad on the environment. If modern software wasn't Turbobloated you would buy new hardware only when the previous hardware broke and wasn't repairabl…

"Screen resolutions from 320x200 to 800x600."

Still, higher resolutions were not just invented because of Turbobloat.

Re: Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

#56

> When all of the patterns get used, I will delete the project and rewrite it in Rust. With no OOP. https://racenis.github.io/tram-sdk/patterns.html Love it.

Woah, it's cutting it close - just 3-5 aren't used! The Rust port might be on the horizon :D

Re: Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

#57

> Most Unity games look like very bad, even with fancy shaders, normal mapping and other techniques. This seems to be an increasingly common point of view among those of a certain age. It is definitely the case that the art of a certain sort of texture mapping has been lost. The example I go back to is Ikaruga, where the backgrounds are simply way better than they have any right to be, especially a very simple forest…

Yes. And the thing is, some modern games ARE overcast with no dynamic lights, and then go on to use Lumen of all things. This was the case with Silent Hill remake, and that thing runs very slowly, looks WORSE on PS5 Pro, the grass looks worse than in older games and so on.

Seriously, the plot of Silent Hill was invented to justify optimization hacks, you have a permanent foggy space called "fog space" to make easier to manage objects on screen, and the remake instead stupidly waste a ton of processing trying to make some realistic (instead of supernatural looking) fog.

Re: Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

#59
post #27

I wholeheartedly agree with the turbo bloat problem. Machines are so much more powerful nowadays, but most programs feel actually slower than before. Very cool project. And the website design is A+

I don't understand the term "turbobloat", never heard it before (and I've made games), the author doesn't define it and a quick search returns the submission article on Kagi, while nothing relevant at all on Google. So, what does it mean? Just "very bloated"? Edit: Reading around on the website and seeing more terms like "Hyperrealistic physics simulation" makes me believe it just means "very bloated".

I don’t think it is a real word. “Turbo” means “very” or more accurately “extremely,” but is typically only used in a positive context, e.g. turbocharged. That makes the turbobloated neologism ironic and funny.

Re: Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

#60
post #39
post #25

"A thing should be a thing. It should not be a bunch of things pretending to be a single thing. With nodes you have to pretend that a collection of things is a single thing." Just want to say this line was great, very Terry Pratchett. Feels like something Sam Vimes would think during a particularly complex investigation. I love it and hope you keep it moving forward. Haven't gotten a chance to mess around with it, bu…

In isolation, isn't the quote prima facie so bad and so wrong though? We think of collections of things as single things constantly . A human is a collection of body parts, body parts are collections of chemicals, chemicals are collections of molecules, molecules are collections of atoms... and yet at each level we think of those collections as being single things. Not being able to do that is just... absurd. The pro…

Agreed. Type systems are nearly always "temporal" yet are too simply designed to address that.

"Temporal" to mean that at any given slice of time during a running application all objects have a signature that matches a type.

Yet most programming languages only allow compile-time analysis and "runtime" is treated as monolithic "we can't know at this point anything about types"

Post reply on HN