I'd be pretty happy using strictly DirectX, but for two issues:
1) For some users, it performs slower than software mode, depending on the video card. Apparently the software fallbacks are simply terrible in some drivers.
2) For some users, DirectX doesn't seem to work right at all. That's pretty uncommon and I think we've dealt with most of those, but it is what it is.
#2 could probably be dealt with by telling DirectX to force itself into software compatibility mode, but I have no idea if that's possible.
I have to say though I'd be pretty happy exploiting more of DirectX's features if these concerns could be allayed. Tobba mentioned for instance that multiplicative blends would be welcome, and I quite agree. (I've figured out how to do additive blends in both formats, and that's a huge deal, but multiplicative blends would be out of the question in GDI.)
I hate to be the guy... But LibTK and OpenGL are the best alternatives to GDI/DirectX. Best of all, they are dirt easy to use compared to DX, more widely supported, and cross-platform. DirectX has been massively inferior to OpenGL for over five years now. In many areas, probably over a decade.
| |
The BYOND Pager did have an OpenGL render I believe, but I think it was dropped?
| |
The OpenGL renderer was dropped (it was in DS, not the pager). I seem to recall we had issues with OpenGL for some people and it was ultimately dropped for simplicity since we were just using software or DirectX.
I'm not opposed to switching to something else, though; as I mentioned at one point, Tom asked me to look into SDL to see if that would be any easier and we could consolidate our graphics code. SDL didn't work out because it can't do some relatively basic stuff like transformations, but if OpenGL can (without horrendous seam issues, anyway), I'm open to it. | |
@Lummox: These days, OpenGL uses textured quads in GL3D and an orthographic perspective transform for 2D game engines. With a little bit of clever GLSL shader authoring, and a little bit of texture buffering, you can get rid of the rounding issues that cause seams.
| |
Have you looked at SDL 2.0 yet? It recently just came out and has support for hardware-accelerated 2D rendering (compared to the previous 1.x releases). Another benefit is you can statically link SDL 2.0 if you want to.
I have been working on a C++ port of "SkyDrop Delivery" using SDL 2.0 in order to eventually port it to other platforms as well as Windows itself. | |
Ter13 wrote:
@Lummox: These days, OpenGL uses textured quads in GL3D and an orthographic perspective transform for 2D game engines. With a little bit of clever GLSL shader authoring, and a little bit of texture buffering, you can get rid of the rounding issues that cause seams. I've done practically nothing in OpenGL myself, so anything that doesn't come from a canned tutorial is going to require a learning curve that I'd rather not throw much time into. Also, I've learned the hard way to avoid "these days" sorts of features, so newer features may be problematic. | |
Bandock wrote:
Have you looked at SDL 2.0 yet? It recently just came out and has support for hardware-accelerated 2D rendering (compared to the previous 1.x releases). Another benefit is you can statically link SDL 2.0 if you want to. Yes. As I said, I looked into SDL and found it can't do the transforms. That's a really big flaw. There's a library that can do those, but it's badly supported (their site doesn't even link to it anymore), and it's strictly software-based and very slow. And SDL wasn't even an option before 2.0 because of the license. Maybe there's something I'm missing on that, but when I looked up how to rotate sprites I kept getting the same answers: Can't be done without the library. As far as OpenGL, one thing I realized is that the seam problem may not exist, for non-transformed atoms anyway, if we render straight to the target resolution (the actual map size) and then blit to a larger size. IIRC we weren't doing that in past implementations. I suppose there's a chance this could be feasible. | |
To give everyone an update on this, OpenGL seems to be panning out pretty well. There are a couple of minor tweaks I want to do, but I think this will work better than the DirectX driver.
I'm going to go forward with a few more features, with the understanding that they're hardware-mode only and will be documented as such. | |
Is it too late to request a true bitmap font system? One that doesn't require sending image calls down the internet wire?
| |
FIREking wrote:
Is it too late to request a true bitmap font system? One that doesn't require sending image calls down the internet wire? I'm not entirely sure what you mean. We already have maptext, which should handle the needs of most games. | |
Lummox JR wrote:
FIREking wrote: maptext is a funky system in which a font is rendered by a machine specific rendering process. There's no prediction of text width, no exposed methods of measuring the font metrics, and no good way of dealing line breaks. There's also no efficient way of doing drop shadows, which is important in video games for text readability where you don't necessarily know what pixels will be creating the background for which your text is displayed over. The bitmap font system (one that is used in like every video game on SNES for example) is a system that copies pixels to the screen in the same way on every machine (and has the same visual outcome on every machine). Developers define the characters or glyphs with icons or icon_states and the client has some intelligent way of blitting these to the screen without the server having to send it an atom per letter (or an atom with an image overlay per letter) which is largely inefficient and impractical. To summarize, this isn't something we can do very efficiently on our own, and maptext was a great feature but doesn't replace bitmap fonts. There is still a font / text rendering void to fill. | |
I'm with FK on this one. Both modern and retro games still use a lot of bitmap font. Very useful, very nice feature.
| |
Generating such bitmaps on the fly on the server end is impractical without the use of a library like FreeType, as this would have to be done on Unix platforms as well as Windows.
I'm not averse to looking into drop shadow methods for handling maptext. OpenGL seems to be a little iffy on this but people seem to have ways of forcing it to cooperate, so I'm sure there are options. | |
That still won't solve font metrics.
The server would tell the client, "render this sentence at x,y on the screen", the client would then take the icon_states and arrange them accordingly. This is something you'd create for us, like a /font datum or something. Something that would be cached on the client side in the RSC. The client would understand the glyph widths and other details, etc. Considering the server and client both understand details about the images being used to display text, its a no brainer. Drop shadows can be placed within the glyphs themselves by the artist designing the glyphs. | |
FIREking wrote:
That still won't solve font metrics. +1 to this enhancement to maptext. Also, Lummox, that's great that we're potentially getting an OpenGL rendering option! As that would make WINE potentially a lot more compatible! | |
Problem, though: For the server to generate a bitmap font, as I said it would require linking in a library like FreeType. DmiFontsPlus gets around this by having an external program do it for you, but it's not something that could be done easily at runtime with any old font. Essentially I think you're looking for something like DFP but without the icon operations.
| |
The server wouldn't generate anything. The server and client, both, would use an icon as the font.
font/my_font Maybe not exactly that, but something similar. The Display proc sends the "display some glpyhs" message to appropriate clients, and the client itself does the actual rendering. Or it returns a ref that can be output to clients, the client will still do the heavy lifting of actually assembling the glyphs onto the screen. So yeah, I am looking for a solution that doesn't require doing icon operations or using overlays and image calls, or using an atom per glyph. Perhaps the icon editor could even be extended so that you could mark the icon file as a "graphical font", and the properties of the font can be defined within the file itself. Just an idea. | |
Honestly why are we still supporting software-based rendering, I realize specific people may require it due to hardware budgets, but at the same time it's kind of holding back a lot of features because of it.