is presently its sole maintainer,
You can support him:
Investigate possible bug in the collision detector
Pass TestP to SpeculativeCollide and also base MoverGroundPoint off TestP
Make a version of GetEntityGroundPoint that takes ForEntityP
Walk around in-game
Put the stairs back in and try colliding with them
Increase GroundBufferCount from 32 to 64
Think about sorting entities in a render list and scaling bitmaps
Look at the TODO list
Consider sorting and translating the coordinate systems
Take a look at how the buffering currently works
Pull out entity_visible_piece and entity_visible_piece_group into handmade_render_group.h
#include handmade_render_group.h and handmade_render_group.cpp in handmade.cpp
Expand the notion of the PieceGroup so that it tracks everything
Move the rendering outside
Now all the pieces are in one giant buffer, and we have no idea which one goes with which entity
Enable setting the render_basis after moving the entities around
Set the DefaultBasis and point to it
View the results in-game
Move PieceGroup up and give it its own memory
Change all of the draw calls to operate off the PieceGroup
Check it out in-game
The inversion and scaling is all still happening erroneously
Look at what the Push functions are doing
Try and regularise how the rendering works
See how it looks in-game
Investigate why the Bitmaps aren't being drawn in the correct places
It's drawing the same Bitmap
Moment of realisation: Rather than sending the whole loaded_bitmap down, we were using one on the stack
Consider ways to pass the correct Bitmaps
Send the whole Bitmap to ground_buffer
See if that fixes our problem
Get rid of that other DrawRectangle call
Rename entity_visible_piece_group to render_group
Consider how we want to extend the notion of render_group so that you can have multiple things pushed onto this render stack
Consider linked list vs packed set
Add PushBufferBase, PushBufferSize and MaxPushBufferSize to render_group
Introduce AllocateRenderGroup in handmade_render_group.cpp
#define PushSize macro
Allocate MaxPushBufferSize and store it in PushBufferBase
Initialise all of the fields of the render_group
Call AllocateRenderGroup and set MaxPushBufferSize to 4MB
Make the DefaultBasis get allocated and initialise it
Store MetersToPixels rather than GameState and pass it to AllocateRenderGroup
Initialise MaxPushBufferSize and PushBufferSize
Now we've got a problem: When we do PushPiece we can't get one because we don't know where that piece is anymore
Attend to the other issues
Straighten out the PushBuffer situation
See if it works in-game
Blackboard: Compression Oriented Programming
miblo Q: Will things like filters end up in the render_group?
cezonezor Q: How long will the renderer take?
poohshoes Q: Could you give us examples of what some of the simpler things will be in the render_group?
gplwhite Q: Are there any static code analysis tools for C / Visual Studio that will help pick up bugs like unused variables, etc?
d7samurai Q: So are you planning on abstracting away the renderer as a layer, similar to how we separated the platform from the game code, so that the various renderers will be operating on the same data structures?
ezioauditorerevs Q: If you were going to write an algorithm to generate Sudoku puzzles, how would it work?
mr4thdimention Q: Unused variables are a warning on my compiler. Did you turn that warning off? I use an allow local macro when I want it to ignore the variable
jfcatalan Q: Would it make sense for the render_group to contain render groups itself?
d7samurai Q: I meant whether you plan for the data describing what needs to be rendered to be in a format such that it's suitable for both software and hardware rendering
boondoggle42 Q: Will our hero always be taller than the treetops?
We've finished early... or have we?
abnercoimbre Q: Are we keeping the 5PM schedule?
Wrap it up with a recap and closing remarks