colingilbert / projectzombie Goto Github PK

Currently, we have the concept of ZEntity, which is a class which represent 
ZEntities in the system. Various system then use this as a base to create their 
own view of the ZEntity. The current system has only the bare minimums in terms 
of corresponding between the various systems. We need to make this better. For 
Render Entities, this is fine, because it is done through the Command and 
Control systems, and it operates directly on the ZEntities themselves (i.e. 
they have strong cohesion, object oriented cohesion.) However, for the 
correspondence between OpenCL buffers and ZEntities is not so clear. We have a 
function which converts ZEntities managed by EntitiesManager which converts the 
ZEntities into data buffers. It works right now. We may want to make this 
better by implementing a system which does this conversion better.  

VolumeMap works. But it's time for a refactor. Here is a quick 5 min run-down 
of what needs to be change.

1.)
VolumeMap internally should use page x,y. Try to eliminate the page ID to long 
pageX, Y conversion as much as possible. 

2.)
PageRegion should be refactored so it stores the computed value such as page x, 
y. Currently, there is a lot of conversion going, conversions that can be saved 
and reused across different methods. 

3.)
We need to move all the addressable to be vector3s instead of all vector2 as we 
are doing now. Even if we are completely 2d at the moment. 

This is an overall code review request:

-EngineController:
Review the entire EngineController system.

-Game States:
Review the game state system.

-Command and Control:
Review the command and control system.

Note:
For each system, please input any issues, objections, and thoughts.

What steps will reproduce the problem?
1. Do nothing.
2. Happens on shutdown.
3.

What is the expected output? What do you see instead?

We expect no leaking elements from libRocket. Instead during shutdown libRocket 
debugger reports:

47 leaked elements detected.
        (0) #text -> #text < tab:selected
        (1) #text -> #text < tab
        (2) #text -> #text < tab
        (3) tab -> tab
        (4) div -> div
        (5) form -> form#hdrhighform < div
        (6) select -> select#tone_mapper_select_id < form#hdrhighform < div
        (7) selectarrow -> selectarrow < select#tone_mapper_select_id < form#hdr
highform < div
        (8) selectvalue -> selectvalue < select#tone_mapper_select_id < form#hdr
highform < div
        (9) selectbox -> selectbox < select#tone_mapper_select_id < form#hdrhigh
form < div
        (10) select -> select#glare_type_select_id < form#hdrhighform < div
        (11) selectarrow -> selectarrow < select#glare_type_select_id < form#hdr
highform < div
        (12) selectvalue -> selectvalue < select#glare_type_select_id < form#hdr
highform < div
        (13) selectbox -> selectbox < select#glare_type_select_id < form#hdrhigh
form < div
        (14) tab -> tab
        (15) tab -> tab
        (16) div -> div
        (17) form -> form#cineform < div:focus
        (18) select -> select#camera_select_id < form#cineform:focus < div:focus

        (19) #text -> #text < option < selectbox < select#tone_mapper_select_id
< form#hdrhighform < div
        (20) #text -> #text < option < selectbox < select#tone_mapper_select_id
< form#hdrhighform < div
        (21) #text -> #text < option < selectbox < select#tone_mapper_select_id
< form#hdrhighform < div
        (22) #text -> #text < option < selectbox < select#tone_mapper_select_id
< form#hdrhighform < div
        (23) #text -> #text < option < selectbox < select#tone_mapper_select_id
< form#hdrhighform < div
        (24) #text -> #text < option < selectbox < select#tone_mapper_select_id
< form#hdrhighform < div
        (25) #text -> #text < option < selectbox < select#tone_mapper_select_id
< form#hdrhighform < div
        (26) #text -> #text < option < selectbox < select#tone_mapper_select_id
< form#hdrhighform < div
        (27) #text -> #text < option < selectbox < select#glare_type_select_id <
 form#hdrhighform < div
        (28) #text -> #text < option < selectbox < select#glare_type_select_id <
 form#hdrhighform < div
        (29) #text -> #text < option < selectbox < select#camera_select_id:focus
 < form#cineform:focus < div:focus
        (30) #text -> #text < option < selectbox < select#camera_select_id:focus
 < form#cineform:focus < div:focus
        (31) #text -> #text < selectvalue < select#camera_select_id:focus < form
#cineform:focus < div:focus
        (32) selectarrow -> selectarrow < select#camera_select_id:focus < form#c
ineform:focus < div:focus
        (33) selectvalue -> selectvalue < select#camera_select_id:focus < form#c
ineform:focus < div:focus
        (34) selectbox -> selectbox < select#camera_select_id:focus < form#cinef
orm:focus < div:focus
        (35) option -> option < selectbox < select#tone_mapper_select_id < form#
hdrhighform < div
        (36) option -> option < selectbox < select#tone_mapper_select_id < form#
hdrhighform < div
        (37) option -> option < selectbox < select#tone_mapper_select_id < form#
hdrhighform < div
        (38) option -> option < selectbox < select#tone_mapper_select_id < form#
hdrhighform < div
        (39) option -> option < selectbox < select#tone_mapper_select_id < form#
hdrhighform < div
        (40) option -> option < selectbox < select#tone_mapper_select_id < form#
hdrhighform < div
        (41) option -> option < selectbox < select#tone_mapper_select_id < form#
hdrhighform < div
        (42) option -> option < selectbox < select#tone_mapper_select_id < form#
hdrhighform < div
        (43) option -> option < selectbox < select#glare_type_select_id < form#h
drhighform < div
        (44) option -> option < selectbox < select#glare_type_select_id < form#h
drhighform < div
        (45) option -> option < selectbox < select#camera_select_id:focus < form
#cineform:focus < div:focus
        (46) option -> option < selectbox < select#camera_select_id:focus < form
#cineform:focus < div:focus
GuiController::shutDown()

What I think is going on:

It has to do with creation elements (Selection in this case) with c++ code.  
LibRocket has this reference counting thing but you have to manually call 
ReleaseReference on objects. Since I'm new, I'm not sure when to call this 
ReleaseReference. I think you are supposed to call it whenever you add an 
object to something, since the place where you added this object to now has a 
reference of this object, you need to call ReleaseReference after adding, 
manually. This is confusing.  

After refactoring of Screens using factories via Controller the Screen 
transition code is now broken.

Why? 

Reason is because it was wrong previously. You meant to have the MainMenuScreen 
as the root document, but instead DebugScreen was added first thus it was the 
root. So the entire pop/push transition stuff is wrong. 

Need to setup staging and deployment structure. 

-How to stage?

-How to deploy?

-Continuous build systems?

PolyVox::Volume does behind the scene shared_ptr memory management WRT for 
PwoerOfTwo block sizes. In Page generation, for each page we also generate an 
extra value on the shared edge with neighboring blocks. Due to the memory 
access pattern, most of the time this is fine. However, it is possible that due 
to the interleaved processing nature of threads, we could have a memory where a 
PolyVox Block is leaked. 

The plan for fixing this is to use Intel Thread Block's atomic feature and 
basically keep a reference count. Such that, the first person accessing an edge 
will atomic write to a variable that subsequent threads can check, so the first 
thread will have the sole responsibility of generating the value at that edge. 

It's not a show stopper ATM because the thing with memory access patterns 
(basically the access is sequentially across the X's, so most of the time when 
a block is address an shared edge, the neighbor would have moved on already, so 
no memory leakage occurs).

Make Life-Cycle delegate registration process more robust.

We discussed the need to remove Camera from EngineView singleton because we 
need to implement camera events (remember we added Camera there for testing; 
well it's time to implement camera system properly). 

We need to just get rid of EngineView completely. This is NOT a big change 
because we were careful to limit getting stuff from EngineView only in onInit 
functions of the LifeCycle abstraction.

The change is simply change onInit function declares to pass in SceneManager.

But before this can be done you need to implement the Camera system properly as 
Camera is gotten from EngineView!

What steps will reproduce the problem?
1. Make the system unable to find resources need by Console.
2.
3.

What is the expected output? What do you see instead?
Expected output is the proper destruction of system resources. Instead, we see 
that an Ogre exception is caught, and the destruction sequence is initiated, 
but the system crashes in CommandController destructor. 


Please use labels and text to provide additional information.

For some reason, we are NOT using delegate classes with forward declaration. 
This leads to the problem of having to recompile many files every time a new 
event is added, etc. 

Solution:

We already started on this. Implment a ZPrerequisite file and stick forward 
declarations there. Why wasn't this done to begin with? Well, we thought about 
doing that, but somehow decided it was better to do foward declaration in each 
file. But this is a pain. So let's go back to sticking it in ZPrerequisite.h. 
Thanks.

When we switched over to generation the borders first, when iterating through 
the region after border, we didn't change some of the values to reflect the 
fact we first generated the borders. So there is a off by one error. 

It's easy to correct. It's only off by one.

I think the big ugly stripes we see for SkyX ground scattering is caused by 
this. 

The original plan was to have the ability to intercept delegate calls. One 
should be able to filter any sort of event in a generalize way so to intercept 
such delegations upstream from any downstream delegates. Use case: For example, 
in our GameMainState, we have various modules which correspond to the main 
state of our game. Say we want to have an SDK tray. And such that we want to 
disable ControlModule when SDK tray is in view. Currently, we are doing this 
the EngineController level by doing multiple checking in OIS::MouseEvent* 
listeners call-backs. We should implement the system such that when we register 
SdkTray (using the current system) we can specify interception delegates. We 
should be filter it to say we want a single delegate to handle ALL MOUSE 
events, or any particular mouse events. 

This is doable with the current system and SHOULD NOT involve major 
refactoring.  

What steps will reproduce the problem?
1. Keep hold down movement key while paging is loading.

What is the expected output? What do you see instead?

Expected output is continuation of program as normal. What one see for certain 
cases is the system will crash on loading one of the pages.

Please provide any additional information below.

Okay this has been fixed temporarily by locking the movement to 60fps or 
higher. The idea here is when loading pages the game slows down, and the 
movement continues, which causes more pages to load, overwhelming the system 
somehow. When using threading this causes problems. 

Please either fix using something besides locking movement, or put up a loading 
screen when loading takes too long. 

Note: another fix is to move the locking movement thing to somewhere else 
beside locking in the movement module. 

I know onDestroy is supposed to be part of the life-cycle. But we need to use 
more RAII. This is definitely doable. We tried to do this just never got around 
to finishing it.

Some parts uses RAII. We need to use RAII everywhere where possible.