I have been told that the bus between main and video memory is too slow to allow for constant updates to large textures. This seems like it would rule out, say, rendering a screen of a game in software then dumping it to the video card via OpenGL for postprocessing.
However, it is my reasoning that an emulator developer should want to do exactly this. An array of pixels would be easiest for an emulator to work on. Most emulators offer a DirectX or OpenGL mode for better sync, which makes me wonder what's going on underneath.
I'll get to it, then: Would it be feasible for a 320x240 game to be rendered in software, with the screen updates pushed to video memory on VBLANK for postprocessing (upscale, scanlines, etc)?
>rendering a game in software then using gpu post-processing
Why are you such a nigger
Why the FUCK wouldn't you just USE THE DAMN CPU TO HASTEN RENDERING
P.S. LEARN TO USE OPENCL AND SHADERS, THAT IS HOW YOU MODIFY LARGE TEXTURES. IF YOU CANNOT DO IT THIS WAY, THEN IT IS COMPLETELY IMPOSSIBLE, AS IF YOU CODE THE GPU RIGHT, IT IS MORE THAN TEN TIMES AS EFFECTIVE AT PRODUCING GRAPHICAL ALTERATIONS AND FLOPs.
Name:
Anonymous2011-11-12 10:22
>>7 Why the FUCK wouldn't you just USE THE DAMN CPU TO HASTEN RENDERING
Did you mean: USE THE DAMN GPU?
You're making the assumption that I'm trying to write the next Unreal Engine with a software renderer. Don't worry, I'm not an idiot. I wouldn't use software rendering if I was programming a 3D game or a graphically intensive 2D game. In my scenario, I'm interested in programming a very simple roguelike, with about the graphical sophistication of a simple Genesis or SNES game. 1 background layer (that never has to be scrolled and rarely needs to be updated), a sprite layer (with little animation except for idle animation), and maybe a few simple particle effects for, say, casting a fire spell.
A software renderer would appeal to me here because it would be very easy to port to different platforms. If it's possible, I could use the platform's native software rendering (like GDI on Windows) or a hardware accelerated alternative, without needing to update the actual "rendering code" (a few dozen blits).
As another example, I'm pretty sure that SSF (the only good Sega Saturn emulator) uses software rendering for its graphics pipeline (I recall the author saying it was easier to do in software, due to the Saturn's use of quadrilateral primitives), yet still outputting with DirectX and VSYNC. Thinking about this, I'm positive that it's possible, I just don't know how I'd go about doing it.
you can use textures as render target too. and edit them using your GPU
Name:
Anonymous2011-11-12 11:16
>>9 I'm aware of this -- I'm also considering using SFML (an SDL-like library that features hardware acceleration by default, with a 2D rendering engine that basically wraps OpenGL rects up as sprites). If I did go that path, I would render to a framebuffer by default, but also allow for rendering to an FBO, which could then have various shaders applied to it in postprocessing.
The main reason I was interested in software rendering is so I wouldn't have to rewrite my rendering logic for platforms that do or don't support some kind of hardware-accelerated screen updating. It'd be much simpler to write all the blitting code once and have to rewrite the final output stage than have to write both a software engine and a hardware engine.
Name:
Anonymous2011-11-12 11:39
>>1 emulator
wat, why not use GNU-acceleration (corrected by Firefox's spelling checker from GPU-acceleration) for the drawing when the emulated computers are going to have similar or identical interfaces to the hardware.
Name:
Anonymous2011-11-12 12:03
>emulated computers are going to have similar or identical interfaces to the hardware
Who said anything about computers?
Emulators for pretty much anything after the Nintendo 64 take this approach. Most games were programmed for these systems using variants of OpenGL, so the video emulation can be quickly approximated by translating OpenGL API calls into whatever the machine running the emulator uses.
Any system released prior to the N64 (as well as portables), I assure you, has nothing in common with a modern computer in terms of hardware design. There's a very important reason why you could just, say, map the emulated system's sprites to GL Rects:
Scanline interrupts.
Modern games (and video hardware) are created with the assumption that an entire frame is going to be rendered at once during VBLANK. Old games, on the other hand, often worked on the output image as it was being drawn to the screen. Scanline interrupts (generated whenever the screen finishes drawing a line of pixels) were a common way to achieve this. If the system only allows 60 sprites on screen at once, for example, a clever programmer could set the video memory to display 60 sprites on the top half of the display, then change all their positions halfway down the screen, effectively doubling the amount of sprites they could use. A common technique on the Sega Genesis to fake water translucency was to modify the palettes of of all sprites and background layers after a certain scanline (ie "height") had been passed. So partway down the frame, everything becomes bluer, making it look like you're submerged in water.
What about systems that didn't have scanline interrupts? Vert clever programmers could achieve similar effects by counting the exact number of cycles that their code ran for so that they could time up things like backgrounds that scrolled at different speeds to fake depth. Most of the time, if you see an NES game with a background that scrolls slower in the "distance" than it does "up close", the programmer had to exactly time whatever code ran while the display was being drawn. If he was off by a microsecond, the effect would be ruined.
I can go on and on about these techniques, but the point is, emulating these old systems that depended on crazy techniques is waaay more complicated than most people would assume. Even for simple stuff, like using the x86 ADD instruction as a direct replacement for whatever the system uses for addition, is going to fuck up any game that depends on that instruction taking up a certain number of cycles. It's hard enough with one processor, but then what do you do with systems like the Sega Genesis, which has 2 processors that many games require to be perfectly in sync for sound to work properly?
For reference, BSNES, the only accurate SNES emulator, is unlikely to run at 60fps on an i7 machine in the accuracy profile.
Name:
Anonymous2011-11-12 12:47
>>8
Just use fucking OpenCL if you really want to be Aspie about it.
OpenCL can accelerate on GPU if it is available, but runs on CPU also.
As for drawing 2d graphics, if you can't even modify an array and send it to a framebuffer, you are terrible.
Jesus Fucking Christ. Why do "software engineers" suck so much at even estimating even orders of magnitude? No wonder this "science" is such a joke.
Have you ever heard of "mplayer"? It's a video player. It has several output modules, some being OpenGL based (-vo gl). Now, according to your armchair calculations, playing a video like that would never have a chance to work, right? Not even for a 320x240 video¹.
>>6 is right that readback is generally slower. That doesn't stop people from capturing 1280x720 videos at 60 frames per second (while running the fucking game in the first place). What does that tell you?
I mean, it takes literally less than five minutes to look around you and see what is feasible and what is not, because it has been done before to death.
¹ Pedants will point out that video is generally uploaded in YV12 colorspace, which takes less bandwidth than RGB32. You are cordially invited to use a 1920x1080 video and force a software conversion to RGB32 for this test.
>>14
Don't listen to this man! I mean, Jesus Christ, 320x240? That's almost 80000 pixels! Eighty thousand!! No kind of monster system could push that many pixels in a sixtieth of a second.
Even an EISA card might have a hard time keeping up!
1920x1200 real-time software rendering on an i3 2100 (though probably like 30-40 fps)
P.s. when doing shader effects, if you're only do shader effects on color that's fine. However, if you wanted say a glow effect on something eyes, you'd have to constantly transfer the location of the eyes to the gpu (as the gpu dooesn't know where anything is). The same goes for every other graphical effect dependent on information which can't be immediately obtained from the framebuffer.
>>12 Who said anything about computers?
You said emulate, and I assumed you were talking about computers such as the Nintendo FC, the Sony PS, or the IBM PC.
Name:
Anonymous2011-11-14 16:08
And to add to that: There is no point in writing emulators for old computing systems, it's an area that has been Solved.