Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[dreiche2]

hm, I see what you mean about the title screen issue. I guess simply referring to a license.txt might be enough, where then you explain the situation and give a further reference to the LGPL... but still.

I'm going to ask at the SDL mailing list. It's also indeed annoying that the FAQ does not say anything about the "prominent notice" part.

[Baughn]

There are two versions of the LGPL that apply to SDL - 2 and 3. 3 would indeed require you to print a copyright notice next to your own, but I've been talking to an SDL guy, and using 2 is perfectly fine. Moreover, most people apparently print the notice to the command line. I don't think I'd recommend it, though.

I don't know what to recommend, really. Personally, I'd be fine with GLUT, but SDL is more reliable on windows. Let's see.. the mac version of GLUT has no issues, you can use freeglut on linux - no issues there - and windows... no idea.

How about moving the copyrights to an "about" window?

[numerobis]

Either SDL or GLUT would require shipping a .dll with the windows version, since they're not standard libraries (SDL you could link to statically, but then you'd have to ship source code).  This is no big deal given that DF already ships an entire directory structure.  GLUT is standard on mac, which cuts the download a tiny bit; SDL is not -- but again, no big deal.  I don't know the linux situation.

Either way would combine all the versions into one codebase, which would reduce the overhead of shipping for multiple platforms.

But there's another question: why limit ourselves to openGL-based APIs?

[Baughn]

Because they're faster.

SDL might be useful as a fallback, though I'd prefer curses (DF on ssh! Yay! I really might write that!), but the fact is that while modern computers are fast enough to show fullscreen video at, oh, 24fps - it takes some 20-40% of your CPU to do so, depending on cpu and of course screen size.

OpenGL allows us to get the same effect with 0-4% CPU use, by moving most of the work to the GPU. See?

[Shadowlord]

What about using SFML instead? The license wouldn't be a problem: http://www.sfml-dev.org/license.php

[bartavelle]

Because they're faster.

SDL might be useful as a fallback, though I'd prefer curses (DF on ssh! Yay! I really might write that!), but the fact is that while modern computers are fast enough to show fullscreen video at, oh, 24fps - it takes some 20-40% of your CPU to do so, depending on cpu and of course screen size.

OpenGL allows us to get the same effect with 0-4% CPU use, by moving most of the work to the GPU. See?

Blitting 2D sprites should not be that expensive. In fact, I wouldn't be surprised if it was much faster than opengl calls. It's just a bunch of memcpy after all ...

[Baughn]

Yet in practice, it is indeed slower. Anyhow, the pixel-shader approach is just blitting a bunch of control data (eight bytes per tile, no more) to the gpu - via dma, no less - it doesn't really *get* faster.

[numerobis]

We're not showing full-screen video here.  We're blasting a few dozen characters every second to the screen (assuming a properly-working partial_print).  Using OGL for this is overkill, it's causing bugs on some fraction of users who suffer from buggy video card drivers (luckily, not me), plus so far it's actually been pretty slow.

Nevertheless, if OGL it is, I'm sure you'll be able to help get the render cost down to very little (as you did with DF accelerator), and maybe fix the problems people have been seeing with partial_print.  Any improvement is a great thing.

[Baughn]

We're not showing full-screen video here.

You're underestimating the future of the fortress.

Anyhow, it's perfectly possible for there to be a lot of change every frame - scrolling, for example. I'd rather have that be as fast as the no-change case.

[Jorgon]

I have been playing with the source with partial print on to try to solve my problem of corrupted video when minimizing/maximizing and moving across monitors.

Here is what I found:
I added a flag into graphicst (if I remember correctly) to force a full render for one frame. I set the flag in the WM_PAINT event. (There are tons of ways to hook it, I just chose PAINT because it was simple.) This should be very portable to Mac/Linux. I couldn't find an event for moving the window across screens. The only way I could solve that problem is to enumerate the list of screens, and check the window moved event to see if the new/old window position intersects with 2 of the screens.

If you could redraw every frame without a speed loss, you eliminate all of these problems. If you want maximum compatibility, you are stuck with immediate mode with opengl. The default opengl that comes with windows only supports GL_WIN_swap_hint, GL_EXT_bgra, and GL_EXT_paletted_texture extensions, which are all useless to you.

The best way I can think to keep opengl and run fast is to render the changes to texture, then render that texture every frame on one large quad. If the user has any video card from the turn of the millennium, you can use http://developer.nvidia.com/object/gdc_oglrtt.html . If the card doesn't support WGL_ARB_render_texture, you can fall back to glCopyTexSubImage methods. This is only two rendering paths, and should ensure compatibility and maximum possible speed.

This would also free you up to do more interesting things later on with opengl. You could render the play field and gui to their own textures, allowing independent work on each. (Render the play field, then the gui with clear alpha where the play area is.) You could have smoke and steam partially obstruct the view using alpha on another texture.

There are a great number of possibilities that come to mind.

[Baughn]

Here is what I found:
I added a flag into graphicst (if I remember correctly) to force a full render for one frame. I set the flag in the WM_PAINT event. (There are tons of ways to hook it, I just chose PAINT because it was simple.) This should be very portable to Mac/Linux. I couldn't find an event for moving the window across screens. The only way I could solve that problem is to enumerate the list of screens, and check the window moved event to see if the new/old window position intersects with 2 of the screens.

If you could redraw every frame without a speed loss, you eliminate all of these problems.

That's what I'm aiming for, yep. Well, it's not quite /no/ speed loss, but 1-2% should be fine; plus, I've put the actual drawing into a separate thread. Doesn't really matter for the 1-2%, but if someone writes a 2d fallback it'd be handy.

If you want maximum compatibility, you are stuck with immediate mode with opengl. The default opengl that comes with windows only supports GL_WIN_swap_hint, GL_EXT_bgra, and GL_EXT_paletted_texture extensions, which are all useless to you.

I think we can safely assume people will install their GPU drivers, yes? Performance with default drivers is going to suck, no matter what.

The best way I can think to keep opengl and run fast is to render the changes to texture, then render that texture every frame on one large quad. If the user has any video card from the turn of the millennium, you can use http://developer.nvidia.com/object/gdc_oglrtt.html . If the card doesn't support WGL_ARB_render_texture, you can fall back to glCopyTexSubImage methods. This is only two rendering paths, and should ensure compatibility and maximum possible speed.

This would also free you up to do more interesting things later on with opengl. You could render the play field and gui to their own textures, allowing independent work on each. (Render the play field, then the gui with clear alpha where the play area is.) You could have smoke and steam partially obstruct the view using alpha on another texture.

There are a great number of possibilities that come to mind.

Using texture copies is certainly an option, but involves quite a lot of calls - several per tile. Using a pixel shader to do the same job requires only four calls *per frame* as it is now.

Well, you'll see. This is becoming almost workable; I think I'll have something usable by friday. (I'd better, since I lose internet access for the weekend)

[Jorgon]

I whipped something together real quick.

http://www.shiware.com/bc_win_source_rtt.zip

Use the preprocessor define RTT to turn on render to texture, otherwise it is default to original rendering. RTT also forces PARTIAL:YES:2
My changes create a render texture on init. Every frame it activates the render texture before running through Toady's normal, slow immediate mode (PARTIAL) rendering. After it completes, it deactivates the render texture, binds the texture and draws another immediate mode quad covering the screen with it. It ALWAYS redraws the quad every frame.

A rough estimate is about 40 lines of code, took me a couple of hours tops, and most of that was debugging a stupid blending issue in the final step.

My processor usage with Grid set to 160x50 (4x the tiles):
Before changes, 50% to 70% on a single core.
After changes: 0%


This does not have the old hardware pathway, but adding it should be trivial. It should work on any semi modern card.

[Inquisitor Saturn]

I'm not sure about all this technical jargon, but are you saying that you wrote a utility to make DF run faster?

[Jorgon]

I didn't write a utility, I changed the source of toady's battle champs game he released the source for (it is a couple pages back http://www.bay12games.com/forum/index.php?topic=23442.msg261144#msg261144 )

But yes, it makes the game run MUCH faster.

Edit:
Let me clarify. If the game is slowed down by the graphics, it removes that bottleneck. It will not help cat-plosion related issues.

[ravensgrace]

Wow, nice work, Jorgon!