liebranca/dsm

the evil framework.

I'm a self-taught software engineer. I like C and Perl. Currently studying x86 assembly ;>

I read my emails, so you may contact me at [email protected]

dsm's Issues

dsm core cleanup

9/27/20: Rewriting to reflect roadmap changes.

Currently, the render loop sits sort of awkwardly on the global update method. I'm fine with that, but it'll probably be cleaner to move it to it's own file.

Similarly, a lot of methods for input handling are pilling on on top of chmang, which gives me this awful feeling that I'm being too disorderly about it.

So, I'm removing this from the SIN milestone (which I now consider closed) and adding it to the next step: finally getting around to clearing out dsm core and utilizing the additional project to combine the others.

What we want to do:

• Centralization: have one module that gives access only to stuff the user would have to worry about. So no lazily exposing internal SIN methods to main like we do now.

• Organization: put things in their place. Have core module handle the common routines, so the main game loop can be expressed more clearly. Less clutter on the stuff we have to see.

• Tidy up: there's lots of old code from almost a year ago that is absolutely useless now as we've already copied, pasted and completely rewritten it.

Shader fixing

Future Lyeb, I really do hope you're feeling like putting in work because I have some more for you.

TASK LIST

• Move the source code to cpp source files
• Figure out faster specular (or remove it)
• Rethink normal map implementation

Yours truly, your past self.

Unreliable framerate

Alright, so while doing some testing I've realized that the timekeeping functions from Zajec might be slightly off. Since we rely on these to drive the framerate I'd prefer making sure everything is working correctly, so... let's fix this mess before we do anything else.

Task List

• Revise the Zajec timekeeping functions.
• Revise the mouselook methods. They're a bit "shaky" sometimes.
• Implement some joystick input while we're at it. That's always fun.

Finish integrating Gaoler into DarkAge

Gaoler is pretty much done for our current needs. I have however forgotten (for some strange reason) to actually try running physics updates on game objects. So, work out the final details of getting neighboring cells more efficiently in DA_WorldManager and throw a few dynamics on screen to see what happens.

float to frac16 conversion

Task list

• Create float range (i*0.0078125 for i in 128)
• Split float at dot
• Determine sign
• Take closest decimal in range
• Add rounding rules
• Fuse bits into frac16
• Move everything to lybyte and tidy up

Custom types

Task list

• byte
• frac16
• crk & crkraw

Blender integration, episode one

Refine the exporter using the Blender API. Though we already have a "good enough" method using game properties for export attributes and console commands to make BlackMagic calls, because I can't detect when the console is open nor force it to always open up automatically it's kind of an inconvenience.

CHECKLIST

• Scene panel
• Material Panel
• Object panel
• Add a popup base class to the Blender tools.
• Attribute setter operator.
• Make BlackMagic function calls using operators as well.
• Revise material export.

C-like array & file handling

Notes to self

1. Remember to use templates
2. Manage memory responsibly
3. Do nigh-paranoid level of error handling
4. Embrace pointer math

Task list

• Create new file struct for lybyte
  • Opening
  • Closing
  • Reading from stream
  • Writing to new file

• Create new dynamic array struct
  • Initialization
  • Modifying values at index
  • Deallocation

Memory management, chapter one

Navigate through lybyte/file.cpp and lytutils/evil.cpp and determine possible sources of leaking.

Just to be absolutely clear, I know for a fact that the OS is freeing up all memory used during calls to Zajec -- it always does so, eventually that is. The point to this is adding an additional layer of security so that a resource monitor won't fire off on a false positive, making future maintenance not as much of a pain.

Notes to self

1. For methods making use of malloc, declare pointers before the call. We need those addresses to explicitly free up all memory on a non-fatal exit , which would be lost when we return early with a failure. Wrapping these methods may prove convenient.

2. USE FLAGS. With proper failure codes, we can do proper cleanup.

Task list

• Wrap writing/reading methods
• Rework error handling
• Reestructure code to avoid early terminations

Memory management, chapter two

Oh, snap! SIN_END() is leaking.

It happens within MeshBatch.c -- the static global SIN_BATCH_SLOTSTACK allocates memory dynamically, twice. Once for the stack struct itself, and another time for the array it contains.

Obviously, we deallocate the array first and then the struct. SIN uses five such stacks to do housekeeping, four of them deallocate alright, and this one doesn't; the call to free() throws an access violation when it's time for the last one to be fred. Sagon's beard this is annoying. I could swear it's the exact same procedure...

Rain, snow or thunder this must be fixed. I'll see to it.

Baseline classes

As you know, SIN is held together by duct tape and prayers. This must change. NAO.

The first step is recycling old code from dsm core into more neatly classified abstractions, fancy language for clean up your mess. Roughly speaking, we're looking at:

TASK LIST

• Vertex
• Shader
• Texture
• Material
• Mesh
• MeshBatch

Stress-test the new render loop

Last commit I made a ridiculous number of changes to the global update function and introduced object culling into the mix. It works well in a small test scene but I have no idea how well it's going to scale.

So, test, measure, test and test again, fine-tune, fix, cry, you know the drill.

Task list

• Write scene export for BlackMagic
• Build test scene
• See how bad framerate can get

You'll never be an Engineer. So stop lying

@Liebranca You are not an Engineer. You falsely claimed to be an "engineer" in of of your videos. Engineering is not about sitting behind a screen, and pressing keys on a keyboard to write code. No, engineering is far more serious . Engineering is about designing and building real entities, like turbines or buildings.
Software developers have this tendency to make huge and false claims these days. They are not engineers, and will never be engineers, not even close.

Write/read methods for ZJC_FileHandling

The current (wrapped) writing function for crk files IN_writecrk is faulty at appending. Furthermore, insertion of a larger chunk in place of a previous one results in overwrites of data outside the range of the older chunk. Expanding on current methods to streamline reading whole chunks of bytes at a time would be a huge improvement. If we can also design these methods to facilitate copying/buffering of chunks for later pasting in, that'd great.

Task list

• Define bytechunk
• Read chunk from file
• Redouble on paranoid memwards
• Write chunk to file
• Appending
• Insertion
• Deletion

Port Chasm to C

Chasm is currently an OOP mess. Time to step up my game...

Task list

• Rewrite files back to C
• Roll chmang and chcont together