simcop2387/blog
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

New blog post? WOW!

Browse source
This commit is contained in:
Ryan Voots 2014-05-19 13:51:38 -07:00
parent 4a796909c5
commit 3a7b5d8587
1 changed files with 34 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
_posts/2014-05-19-state-of-yage.md Normal file
View file

@ -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