It blows my mind that a garbage collected language without aggregate value types was the language of choice for games on these tiny phones.
Perhaps lower performance was worthwhile over having segfaults.
Before the iPhone, I worked on a few games for what were called "feature phones"
351–360 of 407 posts
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#352I'm not sure that in the present day of massive teams and > $100 million budgets that there's much room for new celebrity game developers to emerge on that scale. Pretty much every gamer knows who he is. Now, even the biggest breakthrough indie game with a 5 person dev team wouldn't become a household name. These days it's the studios themselves that get most of the credit. Which may only be fair: When there's 100+ p…
Some names that come to mind are Jonathan Blow, Rami Ismail and Edmund McMillen
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#353Earlier quoted context omitted.
Refcounting has glitches as well.
The refcounting isn't so bad but freeing and running destructors can pause. There's also memory fragmentation from not having a compacting GC. It's all fixable though.
Though nowadays GC is also “fixable”, and probably more performant than refcounting, at least for non-single-threaded code.
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#354I worked on a J2ME app that needed to access location on phones without GPS, I was in touch with the operator and got a list of cell ids with lat, lon. With that I created a daemon in Symbian that would query the cell id and open up a socket server to give it to the J2ME app. With that we developed an app to request a taxi service, but none of the taxi companies wanted it. Some of the complaints were: 1. GPRS data pl…
> a daemon in Symbian that would query the cell id and open up a socket server to give it to the J2ME app Why not just make the entire app native in Symbian if you require it anyway? Or did the Symbian SDK suck even more than I remember?
I tried to do a college end of year project in Symbian, and couldn't get anything to work for months. This was likely a combination of lack of ability as much as the SDKs problem, but it definitely was not novice friendly.
I pivoted to J2ME with about a week to go in the project and managed to get an MVP working in time, after 3 months of wrestling with Symbian.
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#355In the same vein I remember the first time I was able to use a phone to access "internet" from a computer. The "internet access" that the phone had to offer was called "WAP" and I was communicating with the phone via infrared (wireless \o/), you had to dial cabalistic symbols from the computer and to be really careful using their proxy to avoid sell-an-organ level out of plan charges. After that Android's deceptively…
> After that Android's deceptively straightforward tethering feature was almost saddening... Ha - you should've seen early iPhone tethering. Back in those days, net neutrality wasn't a legal right yet (at least here in the Netherlands), so the carriers would push a profile to your phone that disabled tethering. The solution, of course, was to jailbreak your phone and install a tweak that turned it back on.
I remembered that some apps had passed review and released with hidden tethering feature, then discovered, then banned.
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#356Earlier quoted context omitted.
Back in the before times, taxi drivers knew how to navigate a city just by memory. Give them an address and they'd probably know how to find it. Most likely this app was not navigation. Remember, feature phone, probably had less than a couple hundred MB of memory for the entire device. I assume the app would just give the taxi driver address details and what not.
> Back in the before times, taxi drivers knew how to navigate a city just by memory. Give them an address and they'd probably know how to find it. In what city? London cab drivers famously were (are?) required to pass a memorization test, but in American cities I've had many cab drivers who didn't know their way around. They've been generally better than Lyft/Uber drivers.
In just about every city a cab driver was expected to know where they were going. For more obscure addresses they may have asked for major cross streets or similar, but it was generally assumed that the driver knew where he was going (which led to the inevitable problem when he didn't or when the passenger was not precise in their description of the destination.) You would also always find a Thomas' guide somewhere in the front of the taxi just in case...
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#357Earlier quoted context omitted.
You might have better luck running those old games under Wine or Proton.
There's a Windows version of Wine?
You can run it on WSL, so in a sense, yes - https://reddragdiva.dreamwidth.org/607714.html
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#358Earlier quoted context omitted.
Technically, but they tend to be much harder to hack on. It's trivial to replace malloc/free with my_malloc/my_free - and integrating libraries that replace malloc/free as-is without renaming also tends to be straightforward. In C++, you can overload new/delete to use my_* with little hassle, or placement new to instantiate classes on previously allocated memory directly. Meanwhile, C# and Java provide absolutely no…
C# has structs and support for native heap management, and as of C# 9 very few features missing versus something like Modula-3 or even D. You can provide your own GC on .NET via the COM API. https://github.com/Potapy4/dotnet-coreclr/blob/master/Docume... Just like Java since version 10, https://medium.com/@unmeshvjoshi/writing-your-own-garbage-co...
> C# has structs
And yet so little code uses them that to eschew the builtin GC is to eschew basically the entire .NET framework. Even basic foreach loops go through IEnumerable interfaces - theoretically boxing even structs. They also come with different semantics - sometimes terrfiyingly subtly differences when combined with properties.
> and support for native heap management
IDisposable and friends are awkward fill-ins for proper RAII tools for native heaps.
That said, these options can be incrementally deployed in your existing codebase without resorting to another language, so they're more accessible options
> [links]
Hooking/replacing the GC seems more straightforward these days, than when I last looked into it though! Although, coreclr APIs won't help with Unity, or Mono. OpenJDK is at least used by modern Android these days, so perhaps there's a way to use it's GC customization options...?
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#359I played so many games on feature phones back in the day. You could download .jar files from umnet, etc and install them on just about any phone from any manufacturer.
My favorite was the Pirates of the Caribbean: At World's End game which came out as a tie in to the movie, back when every major film had tie in games.
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#360Earlier quoted context omitted.
At the time, "second screen" was the term I heard used for those types of experience. The only prominent example I can think of these days is kahoot, which is only sort of the same idea.
Ah yes, I'd forgotten about the phrase "second screen". It was going to be big thing until people realized that no one wanted to look at 2 screens at once.
Teenagers now have a third screen (TV + phone for friends + tablet for watching a streamer)