Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ported my C game to WASM, here's every bug that I hit

ernesernesto.github.io

Post reply on HN
Print view View original

111–116 of 116 posts

Re: Ported my C game to WASM, here's every bug that I hit

#111

Post by pjmlp »

koolala wrote: post #110
pjmlp wrote: post #107

Earlier quoted context omitted.

See, this is where knowing the history of bytecode formats since UNCOL, would be relevant. Burroungs (1961), https://en.wikipedia.org/wiki/Burroughs_Large_Systems "In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi-level protection mechanism." "NEWP programs that contain unsafe constructs are initia…

Isn't that like rejecting non-safe Rust code? Unsafe code plays an important role in the hot-loops of our ever-slowing computers.

It does, and like in real life, should be handle with glasses and protective gloves.

Now selling yet another bytecode format as some security wonder.

It gets the pass on the browser, as it replaced the existing plugins model, that's it.

Re: Ported my C game to WASM, here's every bug that I hit

#112

Post by pajko »

pjmlp wrote: post #16
arcadialeak wrote: post #9

I love how WASM is the thing that finally blurred the line between Web and Native programming, formely two realms isolated from each other for a long time. This both develops better awareness of how the code is executed by the hardware, which JavaScript devs often lack, and also brings skilled folks from the Native platforms who seem to be not so against WASM as they were against JavaScript (and all other parts of th…

ActiveX, Alchemy, PNaCL,...

Besides ActiveX, old (<9) Internet Explorer supported VML (Vector Markup Language), which was neither supported by anything else, nor widespread. It could be made dynamic with the help of JavaScript, and the only dynamic example I could remember was an analog clock.

Re: Ported my C game to WASM, here's every bug that I hit

#113

Post by leni536 »

RossBencina wrote: post #94
jcranmer wrote: post #59

Earlier quoted context omitted.

The general struct layout algorithm is that you lay out the first member at the address of the struct (this is guaranteed by C), and then subsequent fields in order (also guaranteed by C). What isn't guaranteed is how fields get their alignment, in particular shenanigans you can do with allocating fields in the padding of their prior field, and bitfields in general are horribly underspecified. In practice, C doesn't…

If you sort your fields by size or manually pad them with natural alignment, and use #pragma pack or equivalent non-standard directives that gets you most of the way there. But yes, avoid bitfields. C++ "standard layout type" is the modern equivalent of "POD" I think.

GP probably meant "POD for the purpose of layout" in the Itanium ABI. It's not the same as standard layout, and POD is not a term in recent C++ standards.

Re: Ported my C game to WASM, here's every bug that I hit

#116

Post by fyrn_ »

flohofwoe wrote: post #92
fyrn_ wrote: post #62

You can get real breakpoints, memory watching, etc in browser with the chrome debugging extension

I would recommend the VSCode WASM DWARF debugging extension instead of the Chrome extension nowadays: https://marketplace.visualstudio.com/items?itemName=ms-vscod... This allows to setup an IDE-like 'press F5 to build and start into a debug session' in VSCode, with the debuggee running in Chrome. E.g. see: https://floooh.github.io/2023/11/11/emscripten-ide.html

More of a helix user these days. I will look into it though.

Thanks for sokol btw, we use it at work for some things. Mainly gfx and the dds encoder

Post reply on HN