AaronCameron.net
What's your point?
Not a Member? - Login or Create an Account...MC Offline
Sunday the 22nd of October 2017 @ 04:41pm
Front Page Projects Your Profile About
[]

Filed Under: Journal - Development - Game Development

Dynamic Streams

2002.11.24 04:53am
Aaron

I've been hammering away at this thing for a few hours now... I guess approaching 9 or 10. Unfortunately (for this stuff anyway) I have contract work to attend to tomorrow, so I have to turn in early. Early being 5am.

Anyway, the stream code is looking good. The compile time is awfully high already because of the templates, but the code is simple and modular, and really flexible. I'll be using this streaming code as the foundation for runtime logging events like errors and messages, system events like mouse movement and keystrokes, network server/client abstraction and quite possibly the GL rendering pipeline. I'm not sure the speed will be adequate for the pipeline, though. It's very likely I could implement a direct translation and skip any buffering, which would allow the same interface and syntax to be used for the rendering pipeline as everything else. Unfortunately, I don't know enough about GL yet to give an intelligent opinion.

Regardless of OpenGL's direct involvement, I'll be able to move forward with porting over more signifigent things like system events now that the streaming arch is done. Hopefully I'll be able to whip something up tomorrow to move a pointer around the screen with the real event management and a hacked GL renderer.

This whole streaming stuff has turned out to be pretty darn nice. Already in just testing it I can see a whole lot of possibilities. Best of all I should be able to implement lots of different applications of the streaming seperately of eachother and keep everything nice and bite-size. With the events, I think I'll look into creating a threadsafe stream varient that can have system events pumped into it with a timestamp so I can pull them out at my leasure. That may not even be necessary, though. I really hate having libraries that require the regular call of a generic 'update' method, though, and I'm not sure how else to get around the problem. Perhaps a globally registered n2lUpdate() call or something that'll pump system events and do any other housework that needs to be done.

Perhaps it wouldn't even be a horrible idea to have the gamecode initalized somewhere other than 'main', and to have the developer call n2lRun( x,y,z, myMain ) or something instead. I hate creating overlays like that, but it might do a good enough job of hiding everything away that it would be easier in the long run. Actually, it might be kind of nice to have some kind of central updating service that can run any number of methods based on oscillators. If the game code were broken down into a rendering, event processing and networking etc. subsections, they could be added as members to a created n2l object all with their own calling frequency and order. I'm a little nervous about keeping things unthreaded, though. I'm even more worried about moving to threading. There's a whole lot I don't know about threadsafing, and I'm worried that I'd just end up slowing things down anyway.

I suppose my only real consern is with the OpenGL flip that waits for the screen refresh before proceeding. With monitor refresh's in the 60hz range... potentially a lower, that would set a huge number of artificial limitations on the system. I'm worried that system event processing and worse, internal game state processing could be seriously choppy with the introduction of a forced wait.

To be honest, though. I'm not even 100% sure that filp waits for the refresh in userland. It may hop off into some wonderful magic land and immediately return... in fact, I can check that out if I dump the framerate of my stupid OpenGL test from a couple of weeks ago. Uno momento...

You can't tell, but time has passed

Well, I don't know if it's video driver dependent, but it would seem that my monitor is set up on a 65hz clock, and I was able to get 100+ fps... so it looks magical. Or unsynced. Unsynced is bad since I'll be looking for a way to sync it later. Oh well. Let's count on magic for now and we'll see what the future holds. I don't see it being THAT hard to implement a threadsafe stream type and turning that into the GL pipeline. Then everything could go along happily with the stream rejecting new geometry while it was waiting for a sync. I'm really thinking that's not going to be necessary, though. I must admit, I'm pretty excited. With a rather minimal amount of effort I've been able to see some real results. It's a long way from a game, but it's still encouraging. I suppose time will tell. And now. I must sleep.

Share:

Keywords:

Reader Comments

Magic

2002.11.25 10:30pm
Thanatos
Not to be negative, but haven't you relied on magic for your graphics needs before? With less than optimum results?

  • Re: Magic

    2002.11.25 10:42pm
    Aaron
    Negativity good. Better to hear it now than an I-told-you-so way down the road.

    Actually, I think it was more the other direction. I've always been too anal about inventing everything. I've spent too much time re-inventing the wheel. Something that I'm actually pretty bad at.

    I think it's a good idea to have a basic knowledge of what's going on, but to some degree to just have 'faith'. At least in that I won't discard code just because "it wasn't invented here".

    The core of the statement is right, though. Just relying on something because it works for me isn't the right way to go about things. I'll have to look further into the actual workings of this stuff before moveing much further. That and start cross compiling everything as early as possible.

©2017 Aaron Cameron