Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Feb 2011
Offline Last Active Oct 22 2016 09:25 AM

Posts I've Made

In Topic: Coding-Style Poll

11 October 2016 - 04:32 PM

I can live with the 80-character-per-line limitation


I've also worked on some projects that set a 150 character line length and then made use of it almost every line, which I found way more annoying than a "short" length, since the seemingly ever longer names for things meant most lines did in fact use that length and then still wrap, to the '(', '=' or other "alignment" symbol half way across the screen.


The people I joined there just had a single code window on a 1080p screen. I on the other hand generally have the solution explorer (or similar) panel, wide enough to fit whatever deep folder structure there was, then to have 2 side by side code windows (e.g. the cpp + hpp, or the structure + builder, and such like). I found that extremely disruptive as it messed up my entire workflow.


Id go for a short length any day.





but the one thing that gets my jimmies rustled is when I encounter the following for literally every function.


The formatting or the need for a doc comment that stated nothing useful?


I've taken a disliking for coding styles that then require a large amount of additional code/text to not tell me anything a couple of words could have. Even if the basic starting point was an OK formatting (e.g. doxygen, javadoc, etc. for comments, always use braces, description names, etc.).


The idea of a formatted documentation block that stands out I quite like, its just when there these massive blocks repeating the same thing (and who even reads those later anyway?).


There also often a source of doing 3 or 4 (slow) rebuilds because the style checker found a full stop in a comment out of place. I then very frequently see simple things with just plain wrong comments and names because someone copy pasted to avoid typing so much.


e.g. builders that just set simple fields because of an immutable object rule, and 4 parameter constructor rule. Maybe OK so far if dont have C++ "const" in most languages, but then the field in the actual object, the getter in the object, the field in the builder, the getter in the builder, and the setter in the builder all get full doc comments fully describing the field.

        /**Set the name value used to build MyObject.
         * @param value fieldWithLongName value to set. Must not be null and be at least MyObject.MIN_FIELD_WITH_LONG_NAME_LEN and ... and ...
         * @return This MyObjectBuilder instance for chaining. Not null.
         * @throws NullPointerException if the name was null.
         * @throws IllegalArgumentException If the name did not meet one of the other requirements.
        public @NotNull MyObjectWithAReallyLongNameBuilder withFieldWithLongName(@NotNull final String value) 
                throws NullPointerException, IllegalArgumentException {


            this.namefieldWithLongName = value;
            return this;

And generally such strict rules just seem to be a massive waste of time. I still come across lots of horrible code that was written to the letter of the style guide / checker. e.g. the ability to combine long repetitive names and lambda/stream features to "avoid branches" for the complexity checker to make a 10 line by 100 column solid block, then repeated 10 times for each of the different fields/arrays being processed.

In Topic: Resources/approach for 3D tile/height map rendering

15 June 2016 - 05:52 AM

Well tried a few things to have chunks with a level of detail based on distance (merging 2x2, 4x4, etc. tiles into a single tile), but avoiding visible seams is proving an issue.

Solved it to an extent by adding vertical edge pieces going down to the lowest height, so at least no gaps to see through. Seems like a bit of a hack though.

In Topic: Resources/approach for 3D tile/height map rendering

03 June 2016 - 01:45 PM

Well yes, hadn't really though about the size maths since each vertex is small lol. Well guess the low-end and laptop GPU's wouldn't be able to render so much in detail anyway.


Since your vertex buffers really never need to change (i cant think of why individual vert positions or normal vecs would need to change on a textured height map) then I would definitely use an immutable buffer.

The heights can be changed slightly at runtime though. e.g. to flatten a bunch of tiles for a building or road. But I guess maybe for such things its OK to just create a brand new buffer and throw out the old one, more or less what I expected a write-only map/unmap to do behind the scenes.



But still, is such a triangle list really the normal approach all these games took/take? Found lots on the things various FPS/third-person games take for indoor areas or comparatively small outdoor areas (to only render the rooms the player can see, and simply lower detail meshes with distance for independent objects/entities), but not so much for large outdoor areas, even though games have been doing it for years while keeping pretty good detail for close terrain.


Is the "100x100 chunks but keeping the borders full detail" a suitable idea, or should I have a better look at algorithms to deal with borders, since I don't really need full detail "lines" joining distant regions? Obviously putting a low-res region directly next to a high-res one while doing nothing else is liable to leave gaps along the edges where the gradient changes.

In Topic: Resources/approach for 3D tile/height map rendering

02 June 2016 - 03:42 PM

Not right now, although its not an immutable buffer, maybe I need to play with the creation flags. At some point id want to update sections where the world gets changed, but all I did in my test was Map/Unmap the constants buffers to take an update camera matrix, cleared the render target, a few Set* calls and the single DrawIndexed. Not even got textures in play there yet.


CPU usage was around 0.5% in task manager (i7-4790K), although didn't run the profiler on it.


EDIT: Actually changing the usage flag was a lot faster, guess the driver put it somewhere the GPU cant access efficiently before, even though i never made it CPU readable. I also only just realized that such a vertex buffer is still 100's of megabytes, depending on how much data I need in a Vertex, so I guess that is not a particularly good thing either.

In Topic: Code vs. drag and drop in Game Maker

02 June 2016 - 11:33 AM

You can translate all the drag and drop parts directly to GML pretty easily. This means you can teach all the important concepts (objects/classes, events, variables, conditionals, inheritance, etc.) within the "simple" drag and drop environment.


GML is however able to go far beyond what those drag and drop actions can do practically.

You can also combine both, create reusable scripts, or even create custom drag and drop components which can make for a good middle ground, and a good introduction to GML.


Personally many years ago I found that a really useful feature, because I was able to basically learn GML that way. e.g. I had a space invaders like game in pure drag and drop.


But then I wanted more complex logic like intelligent turrets that could select the best target, and have some chance of hitting fast targets. Or particle effects for explosions, impacts, etc. rather than simple pre-made animated sprites. Or the ability to load, edit and save levels using text files, not just pre-made game maker rooms, so started to include GML scripts. In the end I had nearly the entire game in GML.


This wasn't out of some drive to learn GML specifically, but as a means to add the features I desired to my game, and not be limited because no drag and drop item existed to do what I wanted.