From 3a7b5d85872e01e9e6b574c628b4cdd45596f1cc Mon Sep 17 00:00:00 2001 From: Ryan Voots Date: Mon, 19 May 2014 13:51:38 -0700 Subject: [PATCH] New blog post? WOW! --- _posts/2014-05-19-state-of-yage.md | 34 ++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 _posts/2014-05-19-state-of-yage.md diff --git a/_posts/2014-05-19-state-of-yage.md b/_posts/2014-05-19-state-of-yage.md new file mode 100644 index 0000000..0d3c19d --- /dev/null +++ b/_posts/2014-05-19-state-of-yage.md @@ -0,0 +1,34 @@ +--- +layout: post +title: "YAGE" +category: +tags: [] +--- +{% include JB/setup %} + +So a few months ago I took up the task of porting [YAGE](https://bitbucket.org/JoeCoder/yage) from D1 to D2. +It's ended up a lot more involved than I initially expected, which isn't unexpected. +I'm still learning D but so far I now have it compiling and partially running. +Along the way I think I've fixed one or two bugs along with introducing +a lot of others, most notably in the threading in YAGE. I'm pretty sure I've +completely screwed that up which is why I'm going to rip it all out and make the +engine run single threaded. That will enable me to actually get the demos running. + +After that I can start to redesign the threading system. I want to get it to be at least three threads: + +1. Game logic - Everything from input to simulating physics +2. Rendering - This includes all visual animations, such as texture animations and non-physics affecting animations (e.g. a windmill rotating in the wind). +3. Sound - I want to seperate this out as well since I see it largely as a 1D renderer, mixing samples and doing other things like positional audio. + +I don't know that this is the best way to seperate things but it seems like a reasonable way to handle it for newer machines today. +It may increase latency so I'll need to try it and tweak it but I'm hoping that handling it this way will enable me to make +the threaded design work well as just a message passing interface, which enables a clean design. It also then models the way many +arcade and console systems of yore (even the N64) handled things with dedicated processors to each of these things, so it should be workable. +It will mean some forethought must be put into the design of how things are passed back and forth for each game. + +After the threading I'll be taking the Rendering engine and revamping/redesigning it to take advantage of at least OpenGL 3.1. It seems to +be doing fairly well as it was using OpenGL 2.1 + lots of extensions that brought it to nearly being 3.0 already, but is still taking advantage +of the fixed pipeline matrix manipulations for the camera and possibly other areas. That will enable actual use of geometry shaders which will +make instancing of things much easier to implement. + +You can view my progress on this at https://bitbucket.org/simcop2387/yage