29 comments on “Questioning High Res and 3D Acceleration

  1. One thing to note is not all smoothing methods are created equal. There’s one I call “cartoonization” that would have to be done in a shader, but basically divides the smoothing effect by the difference between adjacent texels.

    You generally need to pick a “floor”, below which the smoothed effect completely takes over, and it’s best to pick a “ceiling”, above which the nearest effect completely takes over. Thus, when sampling between three pink texels and one grey texel, if the grey texel is nearest you’ll get hard grey, but otherwise you’ll get a smoothed blend of the pink texels without any grey.

    Usually, you also apply the same technique to minifying for mipmaps.

    It should really help with that last screenshot… but also with the second.

      • Unfortunately, I’ve never done it as a shader; I normally do it in post, just because my style of graphics is blendier. (Yes, I’m a programmer, not an artist.)

        Conceptually, start with a simple 3×3 blur, but change how you think about it from absolute to relative:
        return OldPixel[X, Y]
        + 1/8 * (OldPixel[X-1, Y-1] – OldPixel[X, Y])
        + 1/8 * (OldPixel[X , Y-1] – OldPixel[X, Y])
        //Etc.
        ;

        At this point, you have a fixed smoothing effect strength — 1/8. The easiest way to make the smoothing effect based on the difference involves a “pivot”, the difference that will be the same as the fixed value. This can be implicit, for example:
        return OldPixel[X, Y]
        + sqrt(OldPixel[X-1, Y-1] – OldPixel[X, Y])
        + sqrt(OldPixel[X , Y-1] – OldPixel[X, Y])
        //Etc.
        ;

        Now the pivot is at a difference of 64, because sqrt(64) = 64/8. A smaller difference will have a stronger effect, like sqrt(4) > 4/8, while a larger difference will have a weaker effect, like sqrt(128) < 128/8.

        However, this isn't magnifying across texels, so start over by applying the same changes to a magnification across texels:
        BaseColor = NearestTexel[X, Y];
        return BaseColor
        + (1-Frac(X))*(1-Frac(Y)) * sqrt(Texel[Floor(X), Floor(Y)] – BaseColor)
        + ( Frac(X))*(1-Frac(Y)) * sqrt(Texel[ Ceil(X), Floor(Y)] – BaseColor)
        + (1-Frac(X))*( Frac(Y)) * sqrt(Texel[Floor(X), Ceil(Y)] – BaseColor)
        + ( Frac(X))*( Frac(Y)) * sqrt(Texel[ Ceil(X), Ceil(Y)] – BaseColor)
        ;

        However, sqrt() is kinda slow, and lacks a ceiling and a floor, so replace it with a custom ease function:
        ease(Diff) =
        (1 – (Min(68, Max(4, Diff))-4)/64) * Diff
        ;

        That's the concept, using a linear ease function. You'll probably want a piecewise linear in the final ease function… of course, none of this code is optimized. However, it's pretty fast since there's nothing hairy and you're only applying one rep. (Doing it as a filter in post, I usually end up doing 16-256 reps, for cellular automaton reasons basically.)

        Also, it turns out I'm nowhere near the first to nickname it that, there's a bunch of stuff on it you can find by Googling "cartoonization"; http://www.youtube.com/watch?v=XwJqDLDAM-k is somebody using a cartoonize filter in post, with all sorts of options for the ease function, and large gaussians and lots of reps and such.

        P.S.: Forgive the lateness of my reply. I thought I turned on email notification of replies.

  2. My best argument for this is that I’ve tried many times to introduce my friends to the wonders of A&A, but everytime my enthusiasm has been met with one simple roadblock. It’s too ugly for them. The game doesn’t hold any kind of charm to them, it’s just a mess of badly rendered pixels they say. And while I can’t completely see their point of view, I do understand where it’s coming from. I’d bet the majority of players are kept from embracing an oldie like this, simply because it’s too old for them to actually get into. If there was any kind of barrier breaker for this, of any sort, I’d say it’s worth it.

    As far as shaders go, that could be a very good route to take. Zsnes has a mode much the same, where pixels are rounded out to form a more cohesive look, but maintaining it’s retro charm. I’m sure there is a solution to this, but sticking to 320×240 just isn’t an option anymore I feel.

    • Nicktendo, I know what you mean about the barrier to entry. I even had a coworker look at it and say something like, “If I had paid for this, I would have felt ripped off!” And I even let him walk around the level a bit. Ouch! But I’m not discouraged that easily. So, yeah, I know about the need to break that barrier. I’m just wondering at what level it breaks — do we have to go to up to Doom 3 level just get them to look at it.

      Thanks for pointing me at the Zsnes shader. More food for thought.

      • No, certainly not that high. I know I myself don’t find the barrier an issue, but then, I’m used to, and fond of older retro style games. Anything from Commodore 64 onwards, so playing A&A gives me enough nostalgia to ignore how dated the game might look. But as you raise that level of fidelity, more players will certainly be enticed. I’m sure Mac’s idea is probably the best way you could take it at this point. After reworking the engine to OpenGL, the options and tools you have would be much more open to take it anywhere you like.

        And even if just the engine is updated at first, the rest can be done later, one level at a time. I only wish I was an artist, I would have been glad to design and draw higher texture/pixeled art for all the items and creatures in this wonderful experience. A&A has been a wonderful feel and memory for me, ever since I first discovered it years ago.

  3. If you decide to go ahead and write an OpenGL renderer for the engine, I’d vote for giving the user the power to change the look and feel for themselves. From running the game at 320×200 up to whatever their monitor supports, and a selection of different texture filtering options or none.

    Another thought; as far as level editing and content creation goes, authors often utilize whatever features are available to them, so supporting higher resolutions and HD sprites might be worth it.

    My two cents.

    • Mac, you make good points. We’ll see what we can do with higher resolution sprites and textures later. In theory, that can be one of the simplest methods of improving the game.

  4. The main factor in whether a game “looks retro” in an appealing way or simply looks old is whether or not the art has consistency. That’s why a lot of people like/tolerate Minecraft. All the graphics have exactly the same style: the enemies are blocks, the items are blocks, the blocks are blocks, etc. Unfortunately, the 2.5d era FPS games with view-dependent sprite frames never had that going for them. They’re a mixture of two different rendering styles that happened to be the best that could be done at the time. This isn’t to say there aren’t fans of this style, but it’s much harder for a newer gamer to get used to it than a game that’s entirely 2d or entirely 3d (either with decent model quality or a consistent aesthetic like Minecraft). Since it’s unlikely for AA to be revamped with all 3d models for now, the best you can do is appeal to players that like the old 2.5d style.

    Regarding resolutions, I like higher resolutions mainly because it lets you see farther. At 320×200, everything’s just kind of a blurry haze in the distance. This can help increase accessibility, and is generally one less reason to criticize the game for newer players. Allowing the player to set the resolution will let players that prefer the older look preserve it. Oh, and enabling higher resolutions will also let custom content use higher resolution textures and sprites meaningfully.

    Texture smoothing should be left up to user discretion, but basic bilinear filtering generally doesn’t look good on low resolution textures. There are alternatives, as has been pointed out in this thread. Note that moving to OpenGL *does not* require you to turn on texture filtering; this can be set up to be fully user-controlled.

    On the renderer topic, I think moving to OpenGL is a good idea simply because it lets you do more with the engine without having to revamp the software renderer. You can look straight up, you can have fully 3d geometry (multiple floors, etc), and so on. It’s also easier to support in the future and easier to extend. Simple things like swapping out fullscreen shaders can greatly change the look of the game, and are a good way to give users ways to customize the look&feel they want. Essentially, OpenGL will give the game more extensibility.

    • About texture smoothing: LuciusDXL on his XL Engine/DaggerXL project has come up with a texture filter that provides all of the benefits of texture minification (rendering textures far away) using bilinear and anisotropic filtering without the downside of texture magnification (rendering textures close up) blurring textures into nonsense at close range. Take a look at his sharp bilinear upscale + anisotropic texture filter here: http://xlengine.com/debugging-and-texture-filtering/ (it’s the second row of pictures). I’m not sure exactly what this filter entails, but it appears to achieve an effect similar to upscaling the base texture before applying filtering to it, so the blur effect is relatively lessened. I believe he achieves this by rescaling the texture coordinates in a shader. Something like this would be the ideal ‘default’ texture filter for A&A, I think. It preserves the retro feel while making the graphics much crisper otherwise.

  5. I realize I’m a month late here, but I wanted to weigh in. I think that your preliminary OpenGL work looks great. To me, being able to see farther is a huge deal (and not being able to is one of my current complaints about the game as-is…the blurriness is dizzying and confusing to my eyes). And I actually like the blocky, up-close sprites. I think it preserves the retro feel. Together they’re a good compromise.

    I also hate pretty much all smoothing — in my book, no amount of smoothing can top just having really crisp blocks.

    This is the approach ZDaemon takes with DOOM engine games, and it’s why I like ZDaemon more than the rest of the DOOM ports.

    • No problem with being a later response. Just to let you and others know, I’ve been working more on the OpenGL and although I don’t have objects back in the game yet, the textures are there and its working. There is some smoothing, but it seems to work well with the walls and floors. I’ve also gotten more familiar with the smoothing options and believe the blocky method will work fine up close.

  6. Unless you can ensure linux support please dear god not unity. In fact I wouldn’t do it anyway unless you wanted a browser based game (and really what would the point be since it’d just represent server load with no actual gains far as I can tell.)

    I’m perfectly fine with fuzzed out edges as the source ports of doom look plenty retro to me and personal opinion is I’d rather have the ability to tell what the hell’s going on over complete faithfulness since staring at a mass of pixels that conveys nothing useful is not fun.

    What I want in this order.

    Remappable controls
    Linux/non-windows Native
    Updated Networking

    Being able to make maps (apparently already done. Good for you guys.)
    Having said mapping able to edit the scrolls/books/dialog/quest text options.

    Engine Extendability (say somehow getting the doom graphics in and making a scifi themed offshoot mod/game. Re-doing all the creature/weapon/item attributes, customize the experience a bit.)

    • I don’t know if you found out yet, but there is the ability to remap the controls in the game now. The networking is working better (but not perfect), but as I said in the other post, it would be cool to rework it. As for Linux, I’ve started making in roads on that and now that my current job uses Linux everyday, that chance is improving daily.
      I’m looking at ways to do extensions and adding/changing scrolls/books/etc. I think I’m closing in on using lua for scripting and using .zip files for new graphics/features. Although I say this too lightly, I’m thinking of reworking a large portion of the game into lua allowing modders to change the game mechanics. But *don’t* take that as a promise yet. I just like how everything looks like it might fit together.

      • Considering most every programming language makes my brain scream i’m noncommittal on lua. I’m sure it’s nice due to not being specific to game like ACS is and not useful elsewhere but so long as basic mapping works.

        Then again I’m halfway convinced Lua actually isn’t as hard to work with as a ‘real’ language like python or c.

        Remappable controls are nice.

        Linux/OS independence are nice.

        Still looking at the let’s play. I hate like your wizards of item destroying. I do not like them at all. Oh well. Gotta have have something to hit the pocketbook somehow.

      • That sounds awesome. Lua is a good choice; it’s used heavily for scripting and modding in many different games. It’d provide a good deal of familiarity for many modders. Like you said, though, I won’t get my hopes up yet. Converting the game mechanics into lua scripts is a ton of work. I’ve had enough experience with that myself to know.

  7. For me the game is unplayable till you make high res version. Also magic system could be remade, and interface.

    • How would you remake the magic system? The current one is pretty cool, IMO. It’s a big part of the charm of the game for me. Making it easier to quickly enter rune combinations during combat would be nice, of course. Now that the game supports mouselook/wsad controls, the combat is much more fluid, but stopping to enter rune combinations takes away a great deal from that fluidity. Something as simple as configurable rune combination hotkey slots (in the style of action bars in MMOs) would basically solve this problem.

  8. “What about using the mouse wheel to scroll through a list of known spells?”
    I see some issues with this solution: if the mousewheel scrolls through *all* of your known spells, it will quickly become unwieldy. There are a lot of spells in AA, so it would take a long time to get to a specific spell. Moreover, I kinda enjoy being able to cast spells I don’t have the scroll for.

    I think both of these problems are resolved by having the ability to assign spells to quickslots/action bars/etc. You could use the mousewheel to scroll through the slots as well (like Minecraft or any shooter with multiple weapons lets you do). That way, you can control how long the list is, and you can directly access specific spells with one key. Skyrim also does something similar to this.

    Of course, all of this involves a lot of UI work, which I can imagine isn’t very fun in AA’s engine. For a simpler option, how about storing the last 5-10 spells (manually) cast in a list, and then allowing the mousewheel to scroll through *only* that list? As you cycle through spells, it can print the spell name you currently have selected on the screen somewhere. That way, you don’t have to create any interactive UI elements. Some way of viewing the spells in the list would be nice, but not immediately critical.

  9. Pingback: I Want to See Less Walls! | Amulets & Armor Developer

      • At this point, why not just have files that you load shaders from? Set aside a dir, add a subdir for unused ones, and display at the main menu or something both which ones are loaded and which nonmatching files were found there, all so it’s hard for a regular user to screw up.

        In addition to a sort of demoscene, modding types will provide shader scripts regular users can just drop in. After distributed effort has settled on something, you may be able to offer it as a patch. (Most modders would happily license their mods for just a credit.)

  10. The game runs a 320×240, doesn’t it? It’s a bit too low for me. I would like to play it on 640×480 or something. Can we please ask for a release of a resolution changing patch? Please?

    • I tried to bite off too much at one time and started creating effectively a whole new rendering engine. I think you are encouraging me to do what I originally needed to do again.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s