The Teleport Contest: Port >440k LoC (NetHack) from C to JavaScript
NetHack C 소스코드 44만 줄 이상을 JavaScript로 포팅하는 Teleport Contest가 진행 중이며, Phase 1에서는 C 코드와의 화면 렌더링 완전 일치 여부로 점수를 매깁니다. 참가자들은 Emscripten을 이용한 자동 트랜스파일링 방식과 LLM 기반 코드 생성(Agentic) 방식을 선택해 경쟁하며, 웹 브라우저에서 직접 플레이 및 디버깅이 가능합니다. Phase 2에서는 유지보수성과 코드 변경량을 평가해 최종 우승자를 가립니다. 이 대회는 대규모 C→JS 포팅과 LLM 활용 코드 생성 실전 사례로 AI 개발자에게 유용한 참고가 됩니다.
[TypeScript 10만 줄을 Rust로, Claude Code 실전 포팅기
전 Facebook 엔지니어 Christopher Chedeau가 Claude Code를 활용해 10만 줄의 TypeScript 코드를 Rust로 포팅한 실험 프로젝트. 목표는 Pokemon 배틀 AI 학습용 고속 오라클 구축으로, 1개월 만에 3.5배 속도 향상과 99.96% 일치율 달성. 차분 테스트와 명확한 지시가 성공의 핵심 전략이었으며, AI 코딩 도구의 현주소와 한계를 평가한 사례.
Supercon 2023: Bringing Arcade Classics to New Hardware
The processing power of modern game consoles is absolutely staggering when compared to the coin-op arcade machines of the early 1980s. Packed with terabytes of internal storage and gigabytes of RAM, there's hardly a comparison to make with the Z80 cabinets that ran classics like Pac-Man. But despite being designed to pump out lifelike 4K imagery without breaking a virtual sweat, occasionally even these cutting-edge consoles are tasked with running one of those iconic early games like Dig Dug or Pole Position. Nostalgia is a hell of a drug…
As long as there are still demand for these genre-defining games, developers will have to keep figuring out ways to bring them to newer -- and vastly more complex -- systems. Which is precisely the topic of Bob Hickman's 2023 Supercon talk, The Bits and Bytes of Bringing Arcade Classics to Game Consoles. Having spent decades as a professional game developer, he's got plenty of experience with the unique constraints presented by both consoles and handhelds, and what it takes to get old code running on new silicon.
Why Not Emulate?
For any reasonably tech-savvy person, the first thing that will come to mind when talking about bringing old games to new hardware is naturally going to be emulation. At first glance, it would seem to be the ideal solution: you don't have to recreate the game from scratch, the gameplay should be exactly as players remember it, and there's probably an open source emulator core out there already that you can port over to whatever your target system is.
Depending on the hardware, emulation isn't always viable.
But as Bob explains early on in his talk, it's not quite that simple in the real world. Sure, emulation should provide a perfect recreation of the game, but in practice, there are always differences that will manifest themselves in unexpected ways. Plus modern audiences are often going to expect enhancements (upgraded graphics, online play, etc) that are likely going to require some modification to the original game anyway.
There is also the issue of performance to consider. While this is going to be less of a problem on a modern console, you might be trying to bring the game over to something like a smartphone which may or may not have enough processing power to emulate the original system at the the speeds necessary to deliver the experience you're aiming for.
To illustrate the point, most of Bob's talk covers a particular project he was involved in back in 2001: bringing Namco Museum to Nintendo's Game Boy Advance (GBA).
The Fine Art of Porting
Powered by an ARM7 CPU running at a little over 16 MHz, the GBA wasn't exactly the ideal platform for emulation. At the same time, simply recreating the games included in Namco Museum from scratch wasn't really an option either. Not only would it have been a considerable undertaking, but the final result would have been different enough from the originals that you'd lose that nostalgic charm.
The solution? Porting the games over to portable C code that could be compiled for the GBA. But even here, things wouldn't exactly be smooth sailing. For one thing, Bob points out that you won't necessarily have access to the original source code. So the first step is likely going to be extracting the binary and graphical assets from a ROM of the game -- this could be pulled literally from an arcade cabinet and read into the computer, or if you're pressed for time, perhaps downloaded from one of the seedier corners of the Internet.
After decompiling the game's binary into Z80 assembly, Bob says the next step would be to convert that over to C. The results aren't going to be perfect, but they'll be better than nothing. The resulting C code certainly isn't going to compile on the first go, but you'll get plenty of error messages in the attempt, and that will tell you where you need to focus your attention on. Fixing these issues one-by-one is going to be time consuming, but will be worth the effort in the end. Eventually, you'll get a binary that compiles and actually runs on your target system…but you aren't done yet.
Up to this point you've just been worried about getting the code compiled and running. Whether or not it actually does what it's supposed to do has been only a vague concern. So when you get this far, the binary you run likely won't look or play anything like it's supposed to. For one thing, the graphics are sure to be busted. You'll need to go in there and rewrite the graphics functions so they'll work on your target system while still taking the same inputs as the original versions. That's going to include figuring out how to scale everything to fit your new target resolution.
You'll need to do something similar for handling user input, as well. The original arcade cabinet probably had some memory mapped scheme where reading from an address in memory would tell it which physical buttons were being pressed, so that's going to need to be modified to fit the game's new home.
Keep knocking these issues out as they come up, and eventually you'll have a working game. Sort of.
Getting Up to Speed
The final part of the process is optimization. Bob recalls that, after porting over the original Z80 code and getting it running properly on the GBA, some of the games would only run at a fraction of their original speed. It wasn't because the GBA didn't have the computational power to do the games justice, it's just that the code wasn't working to the system's strengths.
Pole Position running on the GBA.
One trick that Bob details is adding some code that will record each function called by the code, and have somebody play the game for a bit. After you've collected enough data, you'll be able to identify the most commonly used functions and properly direct your optimization efforts.
Unfortunately, there's no magic bullet for code optimization. But Bob does mention some commonly used tricks, such as using pre-computed lookup tables instead of trying to do sine and cosine math in real-time. There's also things the new hardware will be capable of that you might be able to put to use, even with an older game that wasn't designed with it in mind.
Bob gives an excellent example of this in discussing the optimizations for Pole Position. Originally the background objects on the horizon were rendered in the same way the rest of the game was, but this proved to be slower on the GBA than anticipated. So the solution was to take the entire skyline, save it as a pre-rendered image, and use the GBA's hardware scrolling capabilities to move it. Along with a few other tricks, this got the 1982 racer running at the proper 60 frames per second.
Not All Fun and Games
While Bob's talk was focused on a very specific niche, many of the tricks and techniques he describes could be applied to other aspects of software development. Whether it's taking old assembly code and turning it into C that your modern computer can run, or tracking down which functions are worth your time to refactor, there's plenty in this presentation that you can use in whatever software project you might have going on.
Now whether or not your project is as much fun to bug-test as Galaga -- well, that's another topic entirely.
#classichacks #cons #hackadaycolumns #nintendogameboyhacks #codeporting #decompile #reverseengineering #supercon2023
sayzard
GeekProjects News
hackaday unofficial