• entries
570
2427
• views
216941

# Untitled

69 views

Okay, so I've been working on my programmering stuff since I have no internet and its late at night. Basically, that consisted of integrating the texture atlas with the rest of the graphics interface, so that all that crap is hidden. You allocate a texture with -

Texture tex = texBox.loadTexture( "lolbitmap.bmp" );

And boom, everything is already handled for you. I also tweaked the way the draw calls are handled, so instead of just blitting in immediate mode it stuffs the request into a vertex array which gets rendered right before flipping, so it renders with one draw call now like I've been yipping about. The texture manager doesn't fragment *too* badly. It will fragment if you try to fragment it, but if you maintain a constant distribution of texture sizes it generally figures out how to handle it. I'm pretty sure it'll hold up; I couldn't get it to spit out any more errors at me, so I'm considering it fully debugged. If anything happens, it'll pipe up in the Error log channel.

On the log side, I fixed a couple bugs. To be frank, the entire log system is a nightmare. Basically, there's a base class from which everything inherits, LogStream which acts as an interface for all the stream types. Then we have LogAdapter which acts as a PIMPL-type adapter to abstract the streams, so you can swap them out but still have a nicely-maintained common point of access. Or something.

But look at this craziness -

class LogStream {public:	virtual ~LogStream() {};	virtual LogStream& operator<<( std::string ) = 0;		template < class T >	LogStream& operator<<( T in ) {		return operator<<( boost::lexical_cast< std::string >( in ) ); 	}};class LogAdapter :	public LogStream{	LogStream*  _stream;	std::string _prefix;public:	LogAdapter( std::string prefix );	virtual ~LogAdapter();	virtual LogStream& operator<<( std::string in ) {		return this->operator <<( in );	}	template < class T >	LogStream& operator<<( T in ) {		if ( _stream ) return (*_stream) << _prefix << in;		return *this;	}	template < class StreamType >	void setStream() {		delete _stream;		_stream = new StreamType();	}	LogStream* getStream() {		return _stream;	}};

Now, I honestly have no idea what's going on there. But it gets the job done, so who am I to complain?

I'm still working on the HTML exporter (or, to be honest, have yet to start). I'll have to add some more hacks to it for it to work right. Right now all the different log streams have power to is add a prefix to a message, like DEBUG: or ERROR:. What I need to allow them to do is add a suffix too, so I can make a nice XML format -

Application start.
Display mode set (640x480).
Orthographic projection set (640,480),(0,10).
Atlas allocation failed: invalid dimensions.
Application end.

Why XML? Well, simply because with the wonders of XSLT we can parse that single file into myriad of formats. We can sort by timestamp, or by type. Want to just check for errors? Use the XSLT file to only display error tags. Etc.

Additionally, it would be easier to use XML than HTML if you wanted to write a separate application to view and dissect such files (yay TinyXML?).

Tommorrow, when I'm a little more awake, I'll hopefully design and implement the font support into the graphics interface. I've no idea how I'm going to handle it at this point, but I have an end goal in mind - to be able to load a couple fonts, and be able to color them with vertex diffuse colors. I don't need bolding or anything really.

The way I'm thinking about doing this is to just load the glyphs as alpha masks or something: the entire surface is pure alpha except for the white glyph. Then we can just use the diffuse color to color it however. Shouldn't be too bad - no UNICODE support or anything gross like Steve is doing.

Anyway, sorry for the insanely long post. I just haven't posted anything techical for a couple days, and this is kind of catchup for me. Hur hur hur.

Quote:
 Original post by Mushu The way I'm thinking about doing this is to just load the glyphs as alpha masks or something: the entire surface is pure alpha except for the white glyph. Then we can just use the diffuse color to color it however. Shouldn't be too bad - no UNICODE support or anything gross like Steve is doing.
COPY CAT COPY CAT! :P

I'm doing Unicode because there's absolutely no reason not to. The only difference is that the font code uses std::wstring, and I explicitly call the W version of function (GetTextExtentPt32W, DrawTextW, etc) to generate the glyphs. Which is somewhat LOL.

Quote:
 Original post by Mushu The way I'm thinking about doing this is to just load the glyphs as alpha masks or something: the entire surface is pure alpha except for the white glyph. Then we can just use the diffuse color to color it however. Shouldn't be too bad - no UNICODE support or anything gross like Steve is doing.
COPY CAT COPY CAT! :P

I'm doing Unicode because there's absolutely no reason not to. The only difference is that the font code uses std::wstring, and I explicitly call the W version of function (GetTextExtentPt32W, DrawTextW, etc) to generate the glyphs. Which is somewhat LOL.

Yes, except, as we discussed, static font generation of the entire UNICODE character set is impossible. I'm not going to even bother implementing a runtime font-loading system (yet), simply because, as you discovered, there are some minor issues with loading it into the atlas/sprite manager which make a headache.

I guess it would be possible to do nicely, but it would be more work than just statically loading the ASCII set or something. Hur hur hur.

## Create an account

Register a new account