Live data from Hacker News

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

twitter.com

241–250 of 407 posts

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

#241

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…

[deleted]

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

#242

Yesterday i just ordered myself a feature phone and now I see this tweet about game development on feature phones What a coincidence !!! Anyways has anyone still using feature phone, i would love to hear your experience

What feature phones can get on modern networks? I thought LTE "needed" a smartphone for some reason

https://www.thelightphone.com/

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

#243

I tried running games from 2004 earlier this week and all failed in a spectacular fashion. I thought Windows was all about supporting legacy 32-bit applications.

You might have better luck running those old games under Wine or Proton.

There's a Windows version of Wine?

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

#244
post #83

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

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.

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

#245

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.

I wasn't criticizing Android, I was criticizing Android phones. I'm sure iPhone doesn't implement the protocol perfectly either, but we certainly observed fewer issues. Whether that's because our BT stack vendors did more testing with Apple devices or because Apple has fewer bugs or both, I'm not sure.

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

#246

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.

Don't get me started on programming with BLE on Android. *shudders*

Our management kept asking us to fix these issues with software. We tried things like transparently rebooting our BT module and prompting the user to do common fixes (e.g., "turn your phone off and on again") but most of the time these wouldn't work, unsurprisingly.

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

#247

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…

To be fair, all 3 of those are valid complaints. #1 was true all the way till ~10 years ago when 3G became popular. #2 is still true is most 'urban' areas. People just take their phones with them when they get out of their cars. #3 is interesting - I think some regions had tried to ban mounting phones on the dashboard, but at this point, they must have given up

Confirming #2: I live in Switzerland (low crime rate etc...) but I would not even dream of leaving my phone visible in the car.

Btw. in the 90' I used to detach each-single-time that I parked the car the front panel of the car's radio to then carry it with me (leaving the storage box in front of the passenger seat open, to show that I didn't just put it in there) to discourage people from breaking into the car to extract the radio (front panel & main car radio were individually coded to only work together, that's at least what I believed).

What a silly thing to do, hehe, but to be fair the price of a fancy radio at that time was similar to today's phones ("Pioneer" and "Sony" were high on my list - some models had quite complex display animations/colors/equalizers/etc & sound modes).

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

#248

Earlier quoted context omitted.

If these phones were still around, I'd imagine there'd be another option now: - Write your game in C++ and transpile it to Java using some fancy framework that dances around never using GC.

You'd have to do something like allocate a single byte[] for everything you'll ever need, and reading & writing data would just be a constant tax since you can't just in-place cast that to an int or whatever. It wouldn't be very fun.

But it would be transpiled so the programmer would never need to look at the very ugly stuff. The idea reminds me of the original asm.js

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

#249

Earlier quoted context omitted.

Ultimately it's just as complicated as disabling explicit GC calls, and since we have a lot more RAM to use now you'll get better performance if you just let Java have a bigger heap. To be clear as well, the flag he added doesn't explicitly disable GC, it disables asking for GC explicitly, e.g. it makes "System.gc()" a no-op. The JVM will still garbage collect when it's heuristics decide it should.

Ultimately it's just as complicated as disabling explicit GC calls, and since we have a lot more RAM to use now you'll get better performance if you just let Java have a bigger heap. Will you get better performance? Or will it end up using a large amount of memory and then having a long GC pause that causes your game to drop a frame every now and then?

Every application is different, but I'd wager it would strictly be better. The current GC implementions are very good, especially ZGC for pause times, I'd be surprised if a j2me game had a max GC pause time over 1ms with ZGC.

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

#250

Earlier quoted context omitted.

Ultimately it's just as complicated as disabling explicit GC calls, and since we have a lot more RAM to use now you'll get better performance if you just let Java have a bigger heap. To be clear as well, the flag he added doesn't explicitly disable GC, it disables asking for GC explicitly, e.g. it makes "System.gc()" a no-op. The JVM will still garbage collect when it's heuristics decide it should.

Ultimately it's just as complicated as disabling explicit GC calls, and since we have a lot more RAM to use now you'll get better performance if you just let Java have a bigger heap. Will you get better performance? Or will it end up using a large amount of memory and then having a long GC pause that causes your game to drop a frame every now and then?

The JVM heuristics are quite good, and the GCs are state-of-the-art and a beast, so I doubt you would have frame drops because of GC. More often than not you are better off not tuning the JVM.
Post reply on HN