Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kayamon
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
36 ms
·
361.
▲
by
kayamon
10y ago
WinG didn't come around until 1994 though. If you wanted to ship a game in 1990, you had a choice of using GDI or using MS-DOS. And the "assembly" argument doesn't make any sense. You can program Windows games in assembl
362.
▲
by
kayamon
10y ago
Win32 was designed around DPI-independence from day one. That's why things like GetSystemMetrics exist. Unfortunately, the app developers chose not to use them. GDI was originally designed to run on printers as well as screens, where t
363.
▲
by
kayamon
10y ago
Many compilers now support a range selection extension on case labels, so you can just do: case CMD .. CMD_END: /* whatever */ break;
364.
▲
by
kayamon
10y ago
Borland C used to, and I believe OpenWatcom still does. Haven't seen any other one that did for a long time.
365.
▲
by
kayamon
10y ago
http://lmgtfy.com/?q=awk+windows
366.
▲
by
kayamon
10y ago
Sure, Nintendo make several versions of each cartridge. But they've all been dumped and put on the internet. Whichever version Nintendo chooses to release in their new emulator, it'll already have been dumped by someone else years
367.
▲
by
kayamon
10y ago
Uh... of _course_ it's going to match a ROM found online -- because it's the same ROM, from the same cartridge. It'd be weird if it didn't match.
368.
▲
by
kayamon
10y ago
Did you know the letter 'A' was invented for the 1983 TV show, the A-Team?
369.
▲
by
kayamon
10y ago
<sigh> no it isn't. The word 'patch' was used to mean 'a small fix' hundreds of years before computers were even invented. e.g. patching a hole in a sweater.
370.
▲
by
kayamon
10y ago
> There's nothing inherently slow about LISP. > In other words, whatever assumptions I had about higher level languages and/or garbage collection being bad for game dev were mostly proven wrong. I'm afraid I have to dis
371.
▲
by
kayamon
10y ago
My suspicion is "yes" -- the PS2 wasn't great at memory access, and modern CPU tend to have better caching/branch prediction anyway.
372.
▲
by
kayamon
10y ago
Yeah I noticed that :) I believe it might be the giant if-then chain I use for disassembling opcodes.
373.
▲
by
kayamon
10y ago
Alas, I suspect it's up to Sony whether these things get published :(
374.
▲
by
kayamon
10y ago
> did every function call go through a indirection Yes.
375.
▲
by
kayamon
10y ago
Oh cool, I wondered if ND ever went to the trouble to write one or not. Thanks :)
376.
▲
Disassembling Jak and Daxter
(codersnotes.com)
180 points
by
kayamon
10y ago
|
32 comments
377.
▲
by
kayamon
10y ago
I suspect that this is not using stock Lua, but LuaJIT instead. Stock Lua wouldn't be much different than Python itself. The real gains come from Mike Pall's amazing JIT implementation, not the language itself.
378.
▲
by
kayamon
10y ago
Google actually already does this, based on what you just searched for. Search for "swing", then in the search box, delete that and type in "play". It'll auto-complete with something like "playground swing"
379.
▲
by
kayamon
10y ago
I can't beat the compiler even 0.01% of the time? Really? Because that's the point of the article -- I just grabbed the first piece of C I found and managed to beat the compiler.
380.
▲
by
kayamon
10y ago
All of the compilers I tried automatically detected it and did their own tail-recursion.
381.
▲
by
kayamon
10y ago
It's interesting that your clang and my clang give different results, even though we're using the same version. I suspect it's a result of differing CPU architectures. (i.e. my CPU is a different model to yours perhaps). I or
382.
▲
by
kayamon
10y ago
While it's interesting how you can accelerate Ruby, 150 fps is still _awful_ for a NES emulator on modern platforms. It kinda shows how bad Ruby's performance is compared to most other languages.
383.
▲
by
kayamon
10y ago
It only fails on a _negative_ count. Zero count works. If your program is passing around negative counts, it's already broken, and the exact specifics of where and when the brokenness manifests aren't particularly important. Techn
384.
▲
by
kayamon
10y ago
Yeah, it probably should be. It doesn't affect the performance. The difference would only manifest if you passed in a negative count, which would be an error anyway.
385.
▲
by
kayamon
10y ago
Yeah you're right, I'll fix that.
386.
▲
by
kayamon
10y ago
If the thing you're timing is expected to have a constant running time, the only thing that can slow it down is external factors (e.g. OS background tasks). Best-case over a large number of runs is the correct way to approach the ideal
387.
▲
by
kayamon
10y ago
On the contrary, I've often seen the "you can't beat the compiler" statement. This[1] recent reddit thread has it in the top comment, which is what prompted me to test it out. And while all those other points are fine po
388.
▲
by
kayamon
10y ago
The timing happens directly around the function itself inside the EXE. Compiler settings are in the makefile, full optimization (-O3 or /Ox)
389.
▲
by
kayamon
10y ago
The timing _should_ be constant each run, so best case is the best way to remove the scheduler variations. I tried mean also, and the results aren't that different. Optimization is -O3 (see the attached Makefile at the bottom).
390.
▲
by
kayamon
10y ago
I don't know about Sim City, but it's very _very_ common for games to write everything in C++/OpenGL and just use a thin layer to bind against the underlying platform where needed. In fact, other than using a premade engine l
More ›