111–120 of 407 posts
I worked at a startup, Javaground [1], where we ported and developed games for J2ME phones. We had a room full of dressers full of all the different mobile phones of the day. Each phone had different implementation quirks, such as variable audio delay when playing a file, audio/image formats that were faster/slower, odd button events (some used press, some used ondown, some had no ondown, etc). A lot of our work was…
The chain all in one place, such that it's readable: > Before the iPhone existed, I worked on a few games for what were called "feature phones": Doom RPG 1&2, Orcs&Elves 1&2, and Wolfenstein RPG. Qualcomm's native-code BREW platform had better versions, but I haven't seen any emulators and archives for it, so they may be lost at this point. The J2ME (java mobile) versions are still floating around, and can be emulate…
Thank you. Twitter's user experience is the worst.
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.
- Write your game in C++ and transpile it to Java using some fancy framework that dances around never using GC.
Earlier quoted context omitted.
In case you want a simple explanation for this story: he tried to run an old pre-iPhone mobile game on a computer. The game runs very slow on computers, which is surprising considering the performance difference between these old phones and a modern computer. The reason turned out to be that the game runs a memory cleaning command to avoid bugs arising from lack of space. Since modern computers have 10000x more memor…
It seems kind of crazy to me that people were using a GC language on a device with 128kB of memory. John even mentions how he was forced to run the GC on every frame to avoid problems. I would think when you are that constrained you would be closely tracking your memory usage. It's probably a miracle that those games weren't constantly hitching and crashing due to slamming up against the memory limits.
Earlier quoted context omitted.
The Twitter web UI if you are not logged in is purposefully broken. Every so often, it will just show you "access denied" or "you don't have permission". It is the peak of dark patterns.
It seems to require randomly from 1 to 5 page refreshes to display anything (and don't be fooled by helpful retry button, it won't work, you need to use browser refresh). I thought it was just broken, but you say it works when logged in? WTF.
Earlier quoted context omitted.
I'm curious how the UI looks to other people, because "all in once place" isn't really a complaint I can understand about the Twitter UI I'm seeing. There's buttons and stuff between tweets, but with 280 characters per tweet (140 was definitely less readable) they're not significantly more difficult to read on Twitter than they are in the paragraphs you posted.
The Twitter web UI if you are not logged in is purposefully broken. Every so often, it will just show you "access denied" or "you don't have permission". It is the peak of dark patterns.
Dunno why Twitter seems to have completely deprioritized the issue though. They change the error message every once in a while but nothing else.
Earlier quoted context omitted.
It surprises me the number of people who thought they could make money selling emulators, in what is and has always been almost exclusively dedicated to piracy.
I will admit to paying for Bleem! in the long long ago. I still have the CD. Frankly, it was pretty damned amazing.
Earlier quoted context omitted.
Well, malloc and free are black boxes as well. And in typical implementations can potentially take arbitrary amounts of time to run, too. (Though they usually don't.)
It depends on your allocator - ptmalloc, the default linux allocator - is open source, and there's plenty of very robust open allocators (jemalloc, mimalloc, tcmalloc, etc). Understanding how your allocator works can be very important in certain contexts. On windows I'd expect the default allocator to be a black box, but I might be wrong. For garbage collection I strongly recommend this book (on top of the source cod…
The UCRT is at least "source available" on Windows, up to a point, and distributed with the Windows SDK. The release heap codepath is a bit boring:
malloc: C:\Program Files (x86)\Windows Kits\10\Source\10.0.19041.0\ucrt\heap\malloc.cpp
_malloc_base: C:\Program Files (x86)\Windows Kits\10\Source\10.0.19041.0\ucrt\heap\malloc_base.cpp
HeapAlloc: (kernel32.dll alias for ntdll.dll!RtlAllocateHeap() on my machine)
malloc: C:\Program Files (x86)\Windows Kits\10\Source\10.0.19041.0\ucrt\heap\malloc.cpp
_malloc_dbg: C:\Program Files (x86)\Windows Kits\10\Source\10.0.19041.0\ucrt\heap\debug_heap.cpp
heap_alloc_dbg: C:\Program Files (x86)\Windows Kits\10\Source\10.0.19041.0\ucrt\heap\debug_heap.cpp
heap_alloc_dbg_internal: C:\Program Files (x86)\Windows Kits\10\Source\10.0.19041.0\ucrt\heap\debug_heap.cpp
HeapAlloc