Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    8
  • comments
    39
  • views
    9051

About this blog

The tramp of a hobby engine.

My completed games using Unity, Monogame (c#) and an older ogl2/c++ framework. 

asteroidsClone_sm.jpg Asteroids Clone [ Download ]

joustClone_sm.jpg Joust Clone [ Download ]

lightningCommand_sm.jpg Lightning Command [ Download ]

octaball_sm.jpg Octaball [ Download ]

Entries in this blog

Theory GameDev Challenges - Swinging back around

Took an active break with the challenges but happily watched this last year. Pretty cool what's happening in this space on the site and curious now about the challenge fork that has recently appeared. Lots of good things happening on gamedev.net - hope to meet more new people that share the same interest. Alas, I'm in the hobby group which tends to hop me around from technology to technology. This last weekend (and into today) was nice. Minor distractions, work is done, already queued up the next major project to take it to the end of 2019 with dignity. All set, life is good. So I sit down to the youTube and catch up with the who is who and how badly are they doing it. You know...you've been around a while, you recognize what smells right off the .bat Now, I'm not much for wordy blog entries but this must be told. Oh jeebers yes, this was a good smell. So sweet.   A toy 3D triangle renderer in software presented in a 4 part series. The code built is directed to the console but there is available an alternative hardware screen blit approach with the olcPixelGameEngine starter files making it an almost 1:1 follow along. The results are great and really punch home what is going on behind the scenes on our graphics hardware. Point transformations (object space through to screen space), screen clipping of triangles, perspective texture correction. A build up of a 3D environment from his pixel engine. I'm only to part 3 but really happy with the reinforced learning so far. My experience will be different because I refused to take the simple math by function call approach and simply overloaded operators within a couple structs as we went along. The code base is small enough to grasp the majority at once with enough speed to do some interesting future experiments.  So here we are, new software technology in our hands. Is it punchy enough to take the role of gamedev challenge framework?  it's got a real good shot  (screen shot on an old i5 cpu / intel 9300 intergrated graphics) I like it because it takes me back to the old days of a wolfstien like raycaster clone we were learning AI with but this is way faster. It's nice because it's so pure and not bound to a particular target machine. A start code base that can be shared between different os user types. Nothing being done behind your back, it's right there with a couple sprinkles of "actually, yes you can do it", see right here... Thanks for breezing by. MarkK.

GoliathForge

GoliathForge

 

2D GameDev Challenges - January 2018 (Missile Command)

This challenge was a good run because of Implementing coroutine with IEnumerator and yield return Simple Dictionary based texture manager Basic Particle Engine Ripped GameStateMachine from previous monogame project (joust) had fun making flare particles Did I mention, it's not cool unless it has lightning bolts browsed current scifi google images...nice...inspired. Source : MarkK_LightningCommand.zip    

GoliathForge

GoliathForge

 

GameDev Challenges - November 2017 (Pong)

This months challenge was a fun distraction.  Interesting features in this source upload include modern opengl basic framework freetype implementation AVI loader for intro screen Stack based game state experimented with raw input  experimented with c++11 smart pointers Source : MarkK_Pong.zip

GoliathForge

GoliathForge

 

Dragon Attempt

So recently, some dude in the forum was talking about being told dragons cause a technical problem in a games setting. Well, I'm setting out to find out what the real story is. For now...satisfying my artistic side with a mostly finished bust and starting blocking the body... day 2
day3 quickie 10 minute wing test rigging...oh yeah...it's gonna' be a tail slapper...moving on day 4-5 Hit an export snag from blender...typical. Sorted now...it's difficult to get the right settings that play nice between tools. Here is a short clip of the assets in Monogame. Moving to texture and animation. day...umm...not sure anymore. UV's laid, starting paint. Finished Texture on main body
And finally the asset working in game. This last video is a stub of the main menu screen.

GoliathForge

GoliathForge

 

Female Character Upgrade

Experimenting with the 3D side of Monogame. Animation skinning was fairly easy. I was actually surprised because almost anything exported from Blender turns to failure except going to Unity. The FBX importers in the content pipeline are good. More on that later. Today I show one of the main character upgrades. I'm torn between this look(left) and the older cartoon style(right), but leaning toward the new.

GoliathForge

GoliathForge

 

Added My Third Hobby Game

So, I sat down to see what this MonoGame thing was all about.
I used to mess with XNA back around version 2.
Well, I have to say...I liked it. Easy to get up and running. Joust was one of my favorite games from the 80's.
[ Here ] is a link to my hobby remake version. (follow to google drive download location)

GoliathForge

GoliathForge

 

Planet Rendering

Something I've always been interested in is planet rendering.
Although it's been done a few time in Unity already, I'm having a go at it.
It's one of those complicated things that require you to be firing on all cylinders.
Well, I'm not anywhere near close to anything yet, but after playing with noise generation, custom procedural geometry and custom shaders, I have something to show. The image progression below is 3D noise applied to a custom sphere, a detail diffuse added and adjusted color ramp generated from the noise height values, then lastly the first rough pass of generating tangent space and normal maps from the noise height values.

'Kinda fun.
These images would represent the 20,000 km distance.
Now it's getting close to thinking about how to deal with landing on this sucker.






edit: added blended detail normals.
maybe sharpened it up too much...but I'm just going with it.

GoliathForge

GoliathForge

 

Assimp Output Optimization

The assimp, "makes your program sexier".
If you're anything like me, you have an appreciation for simple.
void Model::loadModel(std::string path){ Assimp::Importer importer; const aiScene* scene = importer.ReadFile(path, aiProcess_Triangulate | aiProcess_FlipUVs); // handle error...}Done. Then to get your hands on the data...
aiNode* node = scene->mRootNode;aiMesh* mesh = scene->mMeshes[node->mMeshes[/*multiple mesh index*/]];for(unsigned int i=0; imNumVertices; i++){ aiVector3D = mesh->mVertices aiVector3D = mesh->mNormals // if not null aiVector3d = mesh->mTextureCoords[0/*first uv set*/] // if not null}for(unsigned int i=0; imNumFaces; i++){ aiFace face = mesh->mFaces; for(unsigned int j=0; jDamn that's tight. Doesn't get any better. Love the assimp.
So we take a closer look with a 5k character model. After import, we're given a 30k character model. Hate the assimp. :)
LOL...yes, we know what you did. Vertex duplication to the extreme. Our little lovely, rewrites to a linear index array and dumps vertices per face making indexed array drawing pointless. Keep hold of the love though, because our program is sexier even though the compile time is now measured in eons. Well, that last part makes her a butt-a-face, so I'm sorry sweetie...you go straight to offline process.
Right, so we have our data...it's bloated but it's there.
Time for a justifiable early data optimization.
// optimize out vertex duplicationmyMesh mesh; // holding extracted data from assimp std::vector vv; // vector std::vector vi; // vector indicesfor (unsigned int i = 0; i ].texcoord.x == vv[j].texcoord.x && mesh.vertices[mesh.indices].texcoord.y == vv[j].texcoord.y) { if (mesh.vertices[mesh.indices].position.x == vv[j].position.x && mesh.vertices[mesh.indices].position.y == vv[j].position.y && mesh.vertices[mesh.indices].position.z == vv[j].position.z) { foundVertex = true; vi.push_back(j); break; } } } if (foundVertex == false) { // add new vertex to list sVertex vertex; vertex.position = mesh.vertices[mesh.indices].position; vertex.normal = mesh.vertices[mesh.indices].normal; vertex.texcoord = mesh.vertices[mesh.indices].texcoord; vv.push_back(vertex); vi.push_back(vv.size() - 1); }}Then we write this out to a binary file.
std::string outPath = "NameYourOwnFileFormat";int numVertices = vv.size();int numIndices = vi.size();std::ofstream outFile(outPath, std::ios::out | std::ios::binary);outFile.write((char*)&numVertices, sizeof(int));outFile.write((char*)&numIndices, sizeof(int));for (int i = 0; i , sizeof(sVertex));}for (int i = 0; i , sizeof(unsigned int));}outFile.close();Did I say I like easy...Back on engine side, it's a simple straight read and direct buffer upload.
No muss, no fuss. On the test mesh, we removed ~70% of the duplicated vertices cutting our asset size to about one third of what we were given.
Pretty sweet for an afternoon's play.

GoliathForge

GoliathForge

Sign in to follow this  
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!