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…
Before the iPhone, I worked on a few games for what were called "feature phones"
241–250 of 407 posts
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#242Yesterday 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
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#243Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#244GC 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
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#245Earlier 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.
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#246Earlier 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*
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#247I 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
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"
#248Earlier 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.
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#249Earlier 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?
Re: Before the iPhone, I worked on a few games for what were called "feature phones"
#250Earlier 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?