Messages

46

Programming / Re: Rendering question

« on: July 16, 2013, 02:05:04 PM »

The WM can be the input handler-- all you do is pass the input down to the focused pane and let it decide. A pane will have its own keymap for whatever actions it can perform.

edit: Well-- your input handler will convert input into 'keys', which the pane will map to an action. Basics of keymapping.

47

Programming / Re: Rendering question

« on: July 16, 2013, 08:42:04 AM »

"How is text not tiled? Each character is a tile just as any sprite would be."

Well, when I think of a game with graphical tiles (which is what I mean), I imagine a screen divided up by pixels. And graphical tiles and text characters need not be the same size, and may even overlap. This would seem to require pixel-level coordinates. So how then do you detect changes?

I have been talking solely about console emulation. That means a discrete grid occupied by a single glyph- either a sprite (animated or not) or a text character. If you want to take full advantage of 2D rendering (and have floating text), then you're no longer emulating a console and just doing standard 2D graphics. Things like WMs and Panes still apply, and you may still want to emulate a console but have extra drawing effects, in which case you would just use your canvas to circumvent the console emulation.

There are a few techniques for optimizing 2D graphics, but if you're going all floaty text, then there are likely going to be additional graphical elements that could dirty your screen in unpredictable ways. In this case, you should blit and buffer, which your rendering library will probably do for you as long as you use it correctly.

48

Programming / Re: Rendering question

« on: July 16, 2013, 03:32:37 AM »

So does this mean the console must contain a buffer or something of the sort that stores the state of the screen so it knows what characters have been changed? What do you do when dealing with tiles, where the screen is now single pixels and can also have non-tile objects like text?

Yes, but I'm talking specifically about a console emulator. The Console doesn't even know what the resolution of the application is, so it can't represent pixels (unless you increase the logical resolution of the console in such a way that the canvas can only render each tile as a pixel-- but that violates the entire point of emulating a console).

How is text not tiled? Each character is a tile just as any sprite would be.

OK, but how simple should the drawing instructions the canvas uses be? Considering that a lot of low-level libraries like Curses and SDL do provide some features for text drawing -- wouldn't these be more efficient, or what (and on libraries without it, could be faked anyway)?

You will use those to draw characters into tiles.

Also, another question about panes: the area where the game world is drawn is a pane, no? But don't panes contain widgets? What kind of "widgets" does it have that allow it to represent the game world?

You could say that the Camera is a widget.



Here, consider the following example.

https://dl.dropboxusercontent.com/u/10791198/Rebrogue.swf

And here are the drawing instructions for the above example. This is in HaXe, which is a language with a number of meta-programming features, so some of it may not make sense, but you can see the correlation between method calls and their effect in the above .swf.

Code: [Select]

        var blueOnly = function(c:Int):Int
        {
        var t = c.toRGB();
        t[0] = t[1] = 0;
        return t.toHEX(); };


        var gradient = function(x:Int,y:Int):Int return x*0x110011+y*0x001111;
        var random = function(_,_,_):Int return Math.floor(Math.random() *0xffffff);
               
                       //colors may be an int or a function that takes up to 3 parameters- x, y and original color.
                       //this makes tinting and gradients a no-brainer


                console.setDimension([16,6]);
                console.clean();
                console.begin_draw();
                console.fill_rect([0,0],[16,6],random,random,"#");
                console.fill_rect([0,0],[16,6],null,gradient); //null preserves the original information
                console.plot_char([0,0],"X",0xffffff,0x0);
                console.draw_text([0,1],"Blah blah blah",null);
                console.fill_rect([0,0],[5,5],0xff00ff,0x0f0f0f);
                console.fill_rect([12,3],[16,6],null,blueOnly);
                console.fill_rect([12,0],[16,3],blueOnly);
                console.end_draw();
The value of having a logical console is that we can perform additive drawing without sending more information to the renderer than we need to. Many of the tiles in the above example get drawn upon multiple times, but only one draw call is made for each modified tile (in end_draw). Some of these draws are a function of the original color or only modify colors without modifying text or vice versa. This provides support for transparency, tinting, lighting effects, and other cool things in a way that is concise and flexible.

This isn't getting into a WM, panes, or widgets as I haven't quite finished that up yet, but maybe seeing an example of how it could work will help you rationalize how it should look on the back-end.


Where would tiles fit in here?
In plot_char or fill_rect, if the string passed is length > 1, then the canvas can perform a library look-up to see if there is a corresponding sprite for that string.

49

Programming / Re: Rendering question

« on: July 15, 2013, 09:44:52 PM »

So if I get this right, then the Camera loops through every tile/entity within its field of view each frame, while the actual rendering, which is done by the Canvas, only invokes the actual business-end platform-dependent draw calls for whatever tiles have actually changed? Or is that change-tracking done by the Console?

Change tracking is done by the console. Otherwise, yes.

How simple should the "drawing instructions" be? Just one glyph per instruction? Does this mean that when drawing text (for example), we need a whole heap of drawing instructions for each and every character in the text?

The Console should offer drawing short-cuts. I have 3 right now, draw_text, fill_rect, and plot_char. They all do the same thing in that they gather a list of drawing instructions and send them to the canvas.

I also have stack drawing methods so that a user can put many commands between a begin_draw() and an end_draw() without updating the canvas until the end_draw().

50

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 15, 2013, 07:02:27 AM »

You could do something like this with miniaturized versions of enemy sprites.

Or maybe it'd be better to enforce a one enemy per tile rule?

Or make it so that each terrain type can only hold so many enemies.

But- imo, at that point things are becoming uninteresting in the 1D sense, as you're just emulating 2D in 1D.

51

Programming / Re: Rendering question

« on: July 15, 2013, 07:00:48 AM »

Sorta.

Canvas is an interface that gets filled out by platform dependent code. Essentially, you would put a wrapper for ie. Flash, OpenGL, or Curses here. My canvas interface really only has one method, that is to commit an array of drawing instructions. In this case, each instruction contains a glyph (either a character or a key), a position, foreground color, and background color (I have everything nullable so that we can only pass what information we want).

Console is a logical object that describes the state of the canvas. Drawing information sent to the console is cached and propagated to the canvas for actual rendering. While the Console/Canvas CAN be rationalized as a single interface, I personally prefer composition over inheritance here. The Console does NOT take input. It's purely an obfuscation of the platform rendering library (curses, opengl, flash, html5, etc). We'll have another object that handles the input and mapping, but I don't think that should be bundled with the console (though it could be). "You might say- wait a minute! Any platform rendering library is also going to have a way to get input- shouldn't the console also handle that information?" It's too monolithic for my taste. I want the console to be a one-way object for writing data to the screen. I'd prefer to have some other object deal with the I/O, even if it uses the same reference to the platform that the console does.


The WM->Pane->Widget relationship could be thought of as a tree. The WM is a relative root node, a Pane is a sibling, and a widget is a leaf. The WM is really just a special Pane that caches what child pane is getting input. Any pane could contain any number of other panes, using the same logic as the WM. A widget is an actual drawing object. While a pane may have a background color (or even just a tint), it isn't sending very many drawing instructions (though it could have a title and scroll-bars)- just telling the widgets when they need to send theirs. The purpose of the Pane is to manage the local drawing context-- That is, the relative origin that it's children are being drawn to. In this sense, each widget/pane has a local and global position- where a pane inherently describes a rendering depth.

The Camera should be pretty straightforward. Your logical map stores spatial information. The camera just starts from one corner and iterates through to the next grabbing the asset key of each entity in the map (an empty space or floor tile is also an entity).

Asset Manager - Is a mapping of glyph-codes (an array key/index) to assets. You can ensure clarity by using strings as keys but an enumeration or consts might be more to your liking. The Canvas will receive a drawing instruction in the form of a glyph-code and color information, it will then pass the glyph-code into the asset manager to fetch which asset it is supposed to use, and then draw accordingly. The Asset Manager will likely read a configuration file that describes this mapping. Strings are cool because you can use no-brainer concatenations to  describe different animations if you want. You can even encode information into the key to allow the Asset Manager to parse for and composite a group of glyphs-- such as if you want to show equipment and stuff. That sort of thing should be an afterthought though- as long as you keep things modular it should be easy to implement later.

52

Programming / Re: Rendering question

« on: July 15, 2013, 01:02:14 AM »

How is the pane-handling done with regards to the console object? How does the WM stand in relation to the console object? What provides the features to draw to the panes? What draws to them -- i.e. if there's a pane for the game area, what draws to this?

A WM arranges Panes on the screen in a logical manner and sets which pane has focus (gets input).

A pane is a managed area of the console. Each pane draws to an area of the console that is provided by the WM. Typically , a pane will contain widgets. A widget is managed GUI feature-- a widget could be a line of text, a checkbox, a button, or a paragraph of scrollable text. A pane will likely contain many widgets, each with their own descriptions of how they should be drawn.

As mentioned before, a Camera draws to the pane for the game area. The current game area consists of a logical map of objects (your game grid). The Camera is a logical object that describes what area of the map to render to the pane. If the offset of the camera is consistent with the player's avatar, then it will be a 'chase'-camera (the camera could just be a location and then the pane just draws as much as it can). The camera doesn't really do anything but look at the state of the game (which is the map) and send information.

Now-- if you want to add fancy animations or effects and such, you can use some looping update calls to the map (like, to draw a colorful effect or something), which should cascade through your camera to tell the pane to update the console.

Also, does this console/canvas/WM thing also work when considering a tile-based game? What if you want to make it flexible so one can add both a tile and text version?

Anytime you want flexibility, you just make an abstraction. The difference between a tile and text version is nothing more than how assets are managed. The asset tied to a goblin, for example, isn't 'g,' but a unique-identifier. Then you can have a config file that lists mappings of unique-ids to assets. When the canvas gets text, it draws text, when it gets a unique-id, it looks up the appropriate asset, caches it, and draws that. It could be either a text or a tile- doesn't matter.

If the sprite/tile is animated, then the canvas will need a way to manage that on its end.

53

Programming / Re: Rendering question

« on: July 14, 2013, 11:08:41 PM »

@OP,

I'm working on a cross-platform console emulator right now, and I make a distinction between the logical console and a canvas. The logical console is a container that stores a buffer of all the drawing cells and provides drawing methods. The canvas is an interface that represents the rendering context. The drawing methods of the console send instructions on only what has changed to the canvas, so only new drawing updates take place. The canvas also obviously takes care of resizing and analyzing font metrics to determine how to best fill the screen.

A separate asset manager can parse a file that contains a mapping of keys to assets that will serve as a library for the canvas. This way you can make it easy to modify the graphics with a simple set of instructions. Instead of passing characters, you pass keys through which the canvas looks up the appropriate glyph. You can then do animations logically by simply swapping out the appropriate glyph. You don't even need much foresight here- simply have a key for every action you implement. The animation won't get used unless it exists.

Hmm. However, when one is using the console, does one call the drawing methods for every tile in the world that is visible on the screen each render, or only those that have changed? As the latter means the game logic then needs to inform the rendering system every time something is done to the map. Is that an entanglement of game logic and rendering?

No. That's the responsibility of your canvas. The console represents the graphical state, whereas the canvas is the rendering context. For a Roguelike, you don't really need to use double-buffering, so you aren't redrawing the scene every frame-- instead, you just pass changes to the canvas and the canvas makes adjustments accordingly. Regardless, it's the canvas's responsibility to determine how to handle changes to its own state.

Correct- the Console should not be called in game logic, See below.

And if one wants to do "chase" scrolling (which I mentioned earlier), where the view always scrolls as the player moves, doesn't this require every character on the console to be changed anyway? So how much benefit is there from adding the extra code complexity (as opposed to a simple every-tile redraw loop)?

The Console is a logical object but it's part of the application logic, not the game logic. The other half of it is a window manager. The WM divvies up console regions to different panes and manages the focus pane (the one that gets input). Panes contain widgets and represent pop-up messages, the information log, any UI element, and the game Camera. The WM and its panes could be completely static and super simple, but the abstraction will be valuable regardless.

The Camera is a logical object that describes what drawing information will get sent to its containing pane. Basically, you have a map of the game. The camera describes what region of that map to draw-- in the case of a scrolling game, it will be centered on the player character (and most likely collide with the edge of the map). In this way, the pane can be moved around without affecting what the player sees. You could also have multiple panes with cameras focusing on different things. This is kind of the basics of MVC (model, view, controller).

Oh-- and you will have things that don't get updated on your screen every frame-- UI elements, some duplicate adjacent tiles, etc. It's good practice and should be trivial to implement.

54

Programming / Re: Rendering question

« on: July 14, 2013, 07:37:05 PM »

Just pick something that supports hardware acceleration. All 3d games redraw the entire screen every single frame, so graphics cards are used to it - and we're talking millions of triangles. I'm pretty sure you won't quite get there with roguelikes

You might be surprised how fast poorly written rendering code will bog a card down. Also, how well you write your rendering logic will determine how portable your application is.

Krice: Perhaps check out SFML instead of SDL. It supports windowed hardware acceleration, and is also a little more high level and easy to use.

I think he's using software drawing mode on purpose, as SDL can use opengl for hardware acceleration just as well as SFML.



@OP,

I'm working on a cross-platform console emulator right now, and I make a distinction between the logical console and a canvas. The logical console is a container that stores a buffer of all the drawing cells and provides drawing methods. The canvas is an interface that represents the rendering context. The drawing methods of the console send instructions on only what has changed to the canvas, so only new drawing updates take place. The canvas also obviously takes care of resizing and analyzing font metrics to determine how to best fill the screen.

A separate asset manager can parse a file that contains a mapping of keys to assets that will serve as a library for the canvas. This way you can make it easy to modify the graphics with a simple set of instructions. Instead of passing characters, you pass keys through which the canvas looks up the appropriate glyph. You can then do animations logically by simply swapping out the appropriate glyph. You don't even need much foresight here- simply have a key for every action you implement. The animation won't get used unless it exists.

55

Programming / Re: Special Land Types

« on: July 14, 2013, 06:55:15 PM »

Yea- those, strictly speaking, aren't exactly biomes. A biome may be overrun and redefined locally by a civilization, even terraformed, but that doesn't exactly change the biome in any way.

56

Programming / Re: Special Land Types

« on: July 14, 2013, 12:40:11 AM »

Yea-- You should generate your biomes via spectral parameters and then populate them with additional variance. So, two areas could be marshes, but subtle differences allow certain creatures to thrive-- creating some distinctions. Then you can ascribe names/types/classifications to these biomes after the fact.

57

Programming / Re: What do you think of having books sharing the information instead?

« on: July 13, 2013, 10:20:21 PM »

Yea- you need to ensure that books are providing a unique function each game. If a book identifies a certain class of equipment, unlocks an ability, or provides POIs or directions to new areas, or outlines what sort of dangers you'll expect to find in particular areas, then it has a practical utility.

If it's just information on the meta-game, that shouldn't be in the game-- but a part of the tutorial/wiki.

58

Programming / Re: The right term for terrain difficulty as far crossing it is concerned.

« on: July 11, 2013, 09:14:33 PM »

Savage
brutal
harsh
Primal
Severe
Rigorous

59

Programming / Re: .ttf files

« on: July 04, 2013, 05:15:51 PM »

I don't get it.

Is it the visual shape of the glyph that bothers you or that it occupies a non-square area of the screen?

You need to handle fore/back color rendering either way- so you'll have a rectangular tile that each glyph is rendered on (logically anyways). You will likely be drawing a rect to handle the background-- if a font isn't the shape you want or it isn't monospaced, you can just center it in he tile. Honestly, it's very little trouble and very much worth it to be able to support multiple .ttfs.

60

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 02, 2013, 08:19:22 PM »

AHH!!! YOU STOLE MY IDEA!


I've had a 1D roguelike in draft for a while.


Gameplay will be interested based upon how you use distance and how you make map features meaningful.


Spells that allow you to push/pull enemies, build walls, set explosive tiles- etc, will all make things somewhat interesting.

However, the real advantage of 1D is how easy and cheap (resource-wise) it is to implement atrociously powerful AI. I would keep the number of fodder enemies low and focus on interesting combinations of enemies with cool powers.