Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Before the iPhone, I worked on a few games for what were called "feature phones"

twitter.com

Post reply on HN
Print view View original

251–260 of 407 posts

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#251

Post by kaba0 »

zlynx wrote: post #87
nicetryguy wrote: post #54

GC every frame? Jesus. Gamedevs jump though hoops to avoid it.

Your other choices are: - Never GC via using object pools. This code is nastier than C++ because Java is not intended to be used this way. - GC whenever needed randomly. The game will just pause occasionally. Very annoying as a player. - Write the actual game in C++. Make a few JNI calls here and there. On feature phones I only remember this being possible for some vendor apps.

Depends on when. If we are talking about modern day JVM, than even the non-latency optimized default GC would have So I think writing a game while profiling allocation rates and paying a bit of attention to not spam new everywhere, one should get decent performance without any framedrops. At most, optimize the hot loops with primitives, arrays.

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#252

Post by kaba0 »

jonny_eh wrote: post #244
__s wrote: post #83

Earlier quoted context omitted.

Probably added after profiling on that system found that the GC pauses would fit within frame budget, whereas not running it every frame would have a long pause eventually drop frames

This! If you GC every frame, you can almost guarantee that it runs fast enough to not cause a frame skip.

Only true for Java runtimes at the time. With modern JVMs with generational GCs, it is detrimental even. Profile it, and only let allocation rate increase to an acceptable level that can be reclaimed easily. Or nowadays one can use a low latency GC as well.

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#253

Post by asdff »

ingenieroariel wrote: post #212

I 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…

Point 2 and 3 are baffling to me. Garmins mounted on the windshield have been a thing in vehicles since the early 2000s at least.

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#254

Post by asdff »

surfsvammel wrote: post #239
mwcampbell wrote: post #235

Earlier quoted context omitted.

> 3. Looking at a screen on the windshield while driving was never going to be approved by authorities. The solution to that seems so obvious: make the phone speak to the driver instead. Was turn-by-turn navigation not feasible back then? Or what else am I missing?

This is me guessing: This sounds like before turn-by-turn navigation was possible. If they had to approximate location via a set list of cell ids, then that doesn't give very precise location data. Also, back then, I am guessing, there where not as good map data available, especially not that would fit in a phone. I would also think that this was before synthesised speech was really possible to do on a phone. The wor…

GPS navigation is 90s tech, though. I had garmin barking turns at me in the early 2000s same as siri today. In fact usually better reception than my cell phone if it was a clear day, since cell coverage is still terrible where you really need need it out in the boonies where gas stations are miles and miles apart.

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#255

Post by grishka »

ingenieroariel wrote: post #212

I 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?

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#256

Post by m45t3r »

pjmlp wrote: post #192
m45t3r wrote: post #187

Earlier quoted context omitted.

We have "been blessed" with OEM deviations from AOSP (we have a big number of clients and most of them are using Android because of regional characteristics), but still we have way more issues with customers using out-dated iOS versions than users on those devices. For comparison, we have way more iOS issues than Android ones, even if Android is the vast majority of our user base (~70% of our customers). Anyway, even…

- Bluetooth issues - Camera is hit and miss, even after the renewed API - Apps randomly killed on the background - Intents that don't launch as expected - NDK debugging that cannot attach to the server running on the device - Unstable GPGPU drivers - Keyboard handling - Perfectly working code that needs to be rewritten just because Yeah so much better than J2ME.

You know, even if you're right we still see much more issues in iOS. For example, a simple Xcode minor upgrade can randomly break some flows.

> - Perfectly working code that needs to be rewritten just because

This issue is much more frequently on iOS than Android, since iOS deprecates features much faster and there is no compatibility layer between versions.

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#257

Post by grishka »

pjmlp wrote: post #41
meheleventyone wrote: post #27

Earlier quoted context omitted.

My very first industry job was making J2ME games and oh my god does it still give me nightmares.

If you miss it, just try Android, contrary to Google arguments against J2ME, the fragmentation experience is kept unchanged.

It's gotten much much better in the modern times. Android 2.x would break your app in many spectacular ways, but Google has been steadily adding more coverage to its "compliance test suite" that a device must pass to be eligible for Play Services preinstall. On 4.x, there were some Chinese phones, like Xiaomi and Meizu, that meddled with notifications, action bars and list views, sometimes to the point of making your app crash, and I do remember having to work around them. But if you support Android 6.0+, like many new apps do these days, you don't have to worry much about device compatibility.

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#258

Post by jefft255 »

ascagnel_ wrote: post #220
thaumasiotes wrote: post #173

Earlier quoted context omitted.

Well, they stopped doing it, so perhaps not.

They don't offer emulated games as standalone purchases anymore (and, frankly, the idea that they charged repeatedly for games is insane to me) -- instead, now it's tied to the Switch Online subscription service.

The library of retro games on Switch Online is laughably small and is one of my biggest gripe with the Switch compared to the Wii (U).

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#259

Post by grishka »

viraptor wrote: post #225
throwaway894345 wrote: post #153

Earlier quoted context omitted.

Especially with respect to Bluetooth quirks. Every single phone has a different set of bugs in its bluetooth components, and none of those sets are remotely empty. In the end, we decided we could only afford to support the 5 most popular models of the day and if you don't have that phone, then too bad for you.

That one doesn't seem like purely on Android. I've never seen a device without Bluetooth bugs. The protocol is so complicated and implementation relies so much on chips that never get fixes that I'm surprised it works anywhere.

But then they still insist on removing the headphone jacks because "wireless is better".

Re: Before the iPhone, I worked on a few games for what were called "feature phones"

#260

Post by sithadmin »

asdff wrote: post #254
surfsvammel wrote: post #239

Earlier quoted context omitted.

This is me guessing: This sounds like before turn-by-turn navigation was possible. If they had to approximate location via a set list of cell ids, then that doesn't give very precise location data. Also, back then, I am guessing, there where not as good map data available, especially not that would fit in a phone. I would also think that this was before synthesised speech was really possible to do on a phone. The wor…

GPS navigation is 90s tech, though. I had garmin barking turns at me in the early 2000s same as siri today. In fact usually better reception than my cell phone if it was a clear day, since cell coverage is still terrible where you really need need it out in the boonies where gas stations are miles and miles apart.

GPS nav hasn't improved much since the 90s, but smartphone nav relying on multiple positioning methods has improved remarkably in even the past 5-6 years. It used to be neither a dedicated GPS device nor a smartphone could handle dense urban areas (where buildings cause satellite interference) if you were moving much faster than a pedestrian.
Post reply on HN