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

Minimal Cross-Platform Graphics

zserge.com

Post reply on HN
Print view View original

21–30 of 67 posts

Re: Minimal Cross-Platform Graphics

#21

Post by flohofwoe »

bitwize wrote: post #8
Const-me wrote: post #4

I think this needs much more complexity to be useful. For the rendering, ideally it needs GPU support. Input needs much more work, here's an overview for Windows: http://blog.ngedit.com/2005/06/13/whats-broken-in-the-wm_key... Windows' Sleep() function has default resolution 15.6ms, that's not enough for realtime rendering, and relatively hard to fix, ideally need a modern OS and a waitable timer created with high re…

No direct access to the command buffers of the GPU? No matrix transform routines? No colorspaces besides RGB? Absolute non-starter.

> No direct access to the command buffers of the GPU?

Lol, show me one library that does this without going through an abstraction layer like Vulkan. Details like this are not even documented by GPU vendors and you'd need to reverse engineer every supported GPU architecture yourself.

Re: Minimal Cross-Platform Graphics

#22

Post by flohofwoe »

krapp wrote: post #20
flohofwoe wrote: post #19

Earlier quoted context omitted.

> For the rendering, ideally it needs GPU support. It's a 2D framebuffer library for placing single pixels like in mode 13 *eyerolling* (GPUs are hardly useful for this type of stuff). If you want something more complete, check out the sokol headers (shameless plug): https://floooh.github.io/sokol-html5/ ...but that can hardly be called 'minimal' anymore.

2d graphics are rendered on the GPU nowadays, and rightly so. Even SDL uses the GPU wherever it can, by default.

That's a silly statement. If you want to place single pixels, a GPU won't help in any way. The most efficient way would be to write pixels with the CPU into a mapped GPU texture, and then render this texture as fullscreen quad. That's hardly more efficient than going through the system's windowing system.

For applications like emulators, or making vintage games (like Doom) run on modern platforms, that approach makes a lot of sense.

Re: Minimal Cross-Platform Graphics

#24

Post by krapp »

flohofwoe wrote: post #22
krapp wrote: post #20

Earlier quoted context omitted.

2d graphics are rendered on the GPU nowadays, and rightly so. Even SDL uses the GPU wherever it can, by default.

That's a silly statement. If you want to place single pixels, a GPU won't help in any way. The most efficient way would be to write pixels with the CPU into a mapped GPU texture, and then render this texture as fullscreen quad. That's hardly more efficient than going through the system's windowing system. For applications like emulators, or making vintage games (like Doom) run on modern platforms, that approach makes…

>That's hardly more efficient than going through the system's windowing system.

My intuition says otherwise but I admit I don't have math on hand to back it up.

Re: Minimal Cross-Platform Graphics

#25

Post by zozbot234 »

flohofwoe wrote: post #22
krapp wrote: post #20

Earlier quoted context omitted.

2d graphics are rendered on the GPU nowadays, and rightly so. Even SDL uses the GPU wherever it can, by default.

That's a silly statement. If you want to place single pixels, a GPU won't help in any way. The most efficient way would be to write pixels with the CPU into a mapped GPU texture, and then render this texture as fullscreen quad. That's hardly more efficient than going through the system's windowing system. For applications like emulators, or making vintage games (like Doom) run on modern platforms, that approach makes…

Most vintage systems use something way more complex than a pure CPU-controlled framebuffer for graphics. They generally have some sorts of pre-defined "tiles" used to implement a fixed-width character mode, with the addition of a limited number of "sprites" overlaid in hardware. These video modes could be implemented efficiently by modern GPU's.

Re: Minimal Cross-Platform Graphics

#26

Post by bitwize »

flohofwoe wrote: post #21
bitwize wrote: post #8

Earlier quoted context omitted.

No direct access to the command buffers of the GPU? No matrix transform routines? No colorspaces besides RGB? Absolute non-starter.

> No direct access to the command buffers of the GPU? Lol, show me one library that does this without going through an abstraction layer like Vulkan. Details like this are not even documented by GPU vendors and you'd need to reverse engineer every supported GPU architecture yourself.

I was being sardonic.

Guy writes a library with the design goals of making basic, retro-like graphics functionality easy and fun with a minimum of code, and certain Hackernews dogpile him because it can't be integrated with an AAA pipeline or whatever.

Re: Minimal Cross-Platform Graphics

#27

Post by flohofwoe »

bitwize wrote: post #26
flohofwoe wrote: post #21

Earlier quoted context omitted.

> No direct access to the command buffers of the GPU? Lol, show me one library that does this without going through an abstraction layer like Vulkan. Details like this are not even documented by GPU vendors and you'd need to reverse engineer every supported GPU architecture yourself.

I was being sardonic. Guy writes a library with the design goals of making basic, retro-like graphics functionality easy and fun with a minimum of code, and certain Hackernews dogpile him because it can't be integrated with an AAA pipeline or whatever.

Ah, apologies then :)

Re: Minimal Cross-Platform Graphics

#28

Post by brabel »

Wonderful. I really wanted something like this to do Graphic the "hard way", also the most fun way... I was trying to use Tcl-TK for that but this seems a lot lower level, perfect for what I wanted to do which is to write a small GUI toolkit for tiny apps.

Re: Minimal Cross-Platform Graphics

#29

Post by formerly_proven »

abainbridge wrote: post #3

I used to use a timer to limit the frame rate to 60 Hz too. But on Windows, I found that DwmFlush() seems to act like WaitVSync(), so I've been using that in preference for years now. I think this is undocumented behaviour. I guess what it actually does is wait until the compositor is ready for another frame. To be able to call that function, I LoadLibrary("dwmapi.dll"), and then GetProcAddress(dwm, "DwmFlush").

> Issues a flush call that blocks the caller until the next present, when all of the Microsoft DirectX surface updates that are currently outstanding have been made.

DWM always runs with vsync so presents never happen more frequently than screen refreshes.

Re: Minimal Cross-Platform Graphics

#30

Post by flohofwoe »

zozbot234 wrote: post #25
flohofwoe wrote: post #22

Earlier quoted context omitted.

That's a silly statement. If you want to place single pixels, a GPU won't help in any way. The most efficient way would be to write pixels with the CPU into a mapped GPU texture, and then render this texture as fullscreen quad. That's hardly more efficient than going through the system's windowing system. For applications like emulators, or making vintage games (like Doom) run on modern platforms, that approach makes…

Most vintage systems use something way more complex than a pure CPU-controlled framebuffer for graphics. They generally have some sorts of pre-defined "tiles" used to implement a fixed-width character mode, with the addition of a limited number of "sprites" overlaid in hardware. These video modes could be implemented efficiently by modern GPU's.

Only if you don't have a cycle correct emulator inbetween. Those old school system relied on hard real time timings down to the clock cycle to let the CPU control the color palette, sprite properties etc... at the right raster position within a frame. Modern GPUs don't allow such a tight synchronization between the CPU and GPU, so the best way is to run the entire emulation single-threaded on the CPU, including the video decoding.

(the resulting framebuffer can then of course be dumped into a GPU texture for rendering, but that just offers a bit more flexibility, eg embedding the emulated system into a 3D rendered world)

Post reply on HN