Jump to content
  • Advertisement

MarkK.

GDNet+
  • Content Count

    600
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by MarkK.

  1. MarkK.

    nubDevice_persistence

    From the album: Project - NubDevice

    Achieved scene persistence. Now we're cooking.
  2. MarkK.

    Project - NubDevice

  3. MarkK.

    OpenGL Minimum of 66 verts?

    okay...well, I looked at the code. My attention went to Mesh::MakeBuffers(). You generate a vertex array object but never bind it before your vertex buffer object bind and fill. Assuming a +/=3.3 core profile and a required vao. Other than that, a bit messy. Not easy to look at.
  4. MarkK.

    clean_master.jpg

    From the album: Project - NubDevice

    Source: https://github.com/MarkKughler/NubDevice post tidy up pass. itching to explore. a few visual debug tools stepping up to bat..
  5. MarkK.

    clean_master.jpg

    Feels nice to have this functionality now. The code is ugly. Maybe even a do over. I see what you mean about line picking. Even with the thickened back buffer line size, It's a little wonky. Forgive my stubborn Thank you for the interaction. I can see now how zone management would feel better.
  6. MarkK.

    Important modelling style Question GameAsset

    common is relative. I'm pretty sure Unity does a fine job of some sort of batching under the hood. I was only considering the pro's to option #2 and admit to a bias toward that usage. again, depends on the final usage. I'd consider a full (background, maybe local depending on how big) scene in blender an optimization as long as the textures were also arranged engine friendly. Then detail and dynamic separately. For instance, Unity (I believe) will produce one draw call per material in the mesh. So to reduce this, one has to consider how the engine works instead of what is easier because easier may result as slower. The keyword you'll be after is "texture atlas" that would be the 'common' approach but your implementation may be unique to your game needs. That and vertex grouping types of thoughts I make more important than my artist comforts. Draw call count is a good one for the artist to take the lead on especially in an environment like Unity. https://docs.unity3d.com/2020.1/Documentation/Manual/DrawCallBatching.html you may find interesting, located in the unity manual (graphics/optimizing graphics performance) that speaks to what I'm attempting to describe.
  7. MarkK.

    Important modelling style Question GameAsset

    It depends on what we're doing with or using the data. I would choose the second option but not stop there. If I'm placing multiple 'like' items in a scene (game side) then I'd be thinking about leaving room on the uv space for maybe interior stuffs...but with the goal in mind to limit how many times I have to change textures in my scene. I argue that an artist can also help the result frame rate. The other reason I like the second option is, now we're moving into the modular asset concept. Ton of good to be had here. The first to me is more of a design template approach or fine detail concept exploration before retopology to desired engine spec. But then again, if I'm going for ultra high realism...hard to say, still would be concerned with what couldn't be seen in a high poly requirement. Good looking stuffs
  8. I think we're trying to view unity source, or something like that.
  9. MarkK.

    clean_master.jpg

    I do read the one pixel under the cursor directly but I'm using that back buffer twice per frame. Once to render the gizmo with a much thicker line width (6.0) pick from that. Clear and render the scene and thin lines (1.0) and present that.. yeah, requires a flush...didn't see a reliable way around it. I thought about ray casting or similar but for me the better path is to keep my head on the shader side. My goal is to see how far I can push it in that space...I have some post process (or I guess it's called deferred) hopes and dreams for the point lights humble attempt in the current source branch.
  10. MarkK.

    clean_master.jpg

    One of the things I seemed to have ignored in my hobby career (besides shadow) were the rest of the off screen buffer glory. Learned a bit of magic this week. We're still approaching my comfort zone, but uncharted territory is on the horizon.
  11. MarkK.

    clean_master.jpg

    Half way there. The when works fairly well, still need to wire on the what.
  12. MarkK.

    clean_master.jpg

    currently playing with custom gizmos for a placement tool. Just passed the visual representation bit, moving into the picking realm hopefully tonight. Wish me luck...
  13. MarkK.

    Ray Tracing a Tiny Procedural Planet

    Oh yeah, here we go...
  14. Huh, that's 'kinda neat moments... When you start over from scratch, design aspects become more important. I can't help what I have yet to discover but for the first of I suspect to be many, a happy moment. Mouse input ponder. The usual choice is to constantly redirect the mouse cursor to the center and act from the deltas. I'm starting to hate that. Something about it. So I changed it up a bit where I'm still clipping to the window but wrapping on the left and right edge. This feels better at least to not have to hide the cursor and still not allow to click focus lost. This is what my front end input handling looks like. Now I don't care about mouse sensitivity or delta timing on the camera yaw movement and perhaps puts a skill modifier back on the user. In a sense. #define imp_bool(x) if(input.pAction_map->GetBool(x)) #define imp_float(x) if(input.pAction_map->GetFloatDelta(x) != 0.0f) void Game::update(float deltaTime) { // user input pump imp_bool(cancel) { action_this_frame = quit; } // camera imp_bool(forward) { camera.move(FORWARD, deltaTime); } imp_bool(backward) { camera.move(BACKWARD, deltaTime); } imp_bool(left) { camera.move(LEFT, deltaTime); } imp_bool(right) { camera.move(RIGHT, deltaTime); } imp_bool(up) { camera.move(UP, deltaTime); } imp_bool(down) { camera.move(DOWN, deltaTime); } imp_bool(jump) { } float x = input.pAction_map->GetFloat(mouseX); // 0.0--->1.0 (l--r) float y = input.pAction_map->GetFloatDelta(mouseY); // upper ndc space also camera.ProcessMouseMovement(x * 360.0f, y, true); // yaw rotation based on horz screen position // pitch is accumulated and clamped process side // // todo: take into account the physical velocity of the mouse movement // high velocity user movement skips a beat at edge transition // solution: track previous movement and apply // priority: barely notice-able // POINT pt; ::GetCursorPos(&pt); // keep y component if(x<0) { // left and right screen edge cursor wrapping POINT pt_desired = { display.dims.width, 0 }; ::ClientToScreen(display.hwnd, &pt_desired); ::SetCursorPos(pt_desired.x-2, pt.y); // todo: refactor out the magic number } if(x>0.9985f) { // partial cause of refactor above (but it's decent smooth at 800 x_res) POINT pt_desired = { 0, 0 }; ::ClientToScreen(display.hwnd, &pt_desired); ::SetCursorPos(pt_desired.x, pt.y); } } we'll see how it goes.... Next up... [ Fix your timestep ] yup, I'm a believer. I've heard said, 'If you're going to do multiplayer, do it early'. Hard to argue, set up you system to play nice with something hard. I've always partially ignored the previous state - this state tween concept when it came to timing, but this really, really makes sense to me now. Oh yeah, we're keeping that... And the closer.. I'll be spending the week cleaning up and minor miscellaneous tweaks. I understand the importance of tidying up and now is the point to decide how I branch out from here cleanly. I feel now is a good time to give the [ RIP Method ] a serious follow through. I agree, repetition is key (at least for me) Thanks @DavinCreed, that's helping. I've only started to browse. Have to go to work for now though.
  15. Action Shooter Genre appreciator and dabbler in, wait look at that moments... :) 

  16. MarkK.

    LetThereBeDark

    From the album: Project - NubDevice

    Shadow mapping by hand is a trip... One of those areas for me where I should probably slow down and smell the roses...
  17. MarkK.

    Khronos Releases Vulkan Unified Samples Repository

    Perfect. I indirectly found three glTF related projects of interest applicable to the previous spec. I wish we had public resources like this in the yester-year. Takes time to build it up I suppose. edit: we don't want anyone else handling the news lol...
  18. MarkK.

    The Story Begins...

    Progress Image(191031 Working on door handling makes me remember UDK. Today I push my project to be a little more visible. https://github.com/MarkKughler/NubDevice [dev.azure : NubDevice] project development board Over time, I've glued together more than a handful of starter frameworks. This time I've changed it up a bit and tried for a bit of consistency from the start so new objects feel natural to use. This is working well for shaders, textures, input and the display. I'm actually happy with it as a start. High-lights that may be interesting: start of custom gui (inspired by fpl::flatui) updated stack based state management (menu[n]/play/pause) push in pop out (or maybe old school, first in, last out) .dae loader (geometry and skinning info) (todo: keyframe) currently broken TBN path Hope to finally do some interesting shader work this time around and feel better prepared for the next game challenge. I'm a fan of openAL. That parallel to openGL way is a good thing in my book. Start the device, fill a buffer, attach to a source. Bounce a listener around. It's good. As my interface, that's all I need. A buffer load and a source to play. Fairly clean solution for home brew. Since I don't see a need for the buffer because we don't alter it, I'm thinking of making that init a one liner, except form maybe a reload need. Play from id is great. buffer_click = sound.add("buttonClick"); source_click = sound.attach(buffer_click); // and anywhere alSourcePlay(source_click); // sure why not :) The main character := reveal. nope...still not telling. I'll let you know when I do. heavy current inspiration is an first person arm mesh on the table. Still dreaming up what could go with it proper third person. Choices are fun.
  19. MarkK.

    baddie.jpg

    From the album: Project - NubDevice

  20. MarkK.

    baddie.jpg

    Thar'll be your guy high tech group. Fun aside, lot of work to get there.
  21. MarkK.

    The Story Begins...

    I really want to do this bad. lol. (boat load of great art over here now. Few decent modular packages ready for tweaking) enough character icons to put front and center...just 'gotta make that code sing. I know...should use a upper tier engine...it's just not the same kind of puzzle.
  22. MarkK.

    craft_01_texturePass

    From the album: Project - NubDevice

  23. MarkK.

    craft_01_texturePass

    @Rutin What a wild month. I knew I had an unattended comment in the queue. I've been at it pretty hard, Finally settled on some realistic moves, which are still a bit ambitious for one guy. I'm torn between Unity and home brew which is winning over here. 'Lov the Unity, fantastic tool. For me, home brew scratches that spot just right, so it's hard to resist. With that said, I'm fairly happy with a new raw ogl3 framework I'm putting together. The focus is on getting up and running quickly with the common elements (menu, game state, timing, display management, input, shader management, logging....) so I can get serious with the Challenge Group. I was leaning toward an upcoming code review and/or community source share. (deciding if it's worth it. been wanting to put something in that git thing for quite a few years now.)
  24. At most, a basic map explorer. pixel art is hard...
  25. I see the playing field populating and players taking their turns... Special thanks for this particular challenge opportunity. Full disclosure, I've actually never played Doom. Which made this first week a research exercise. Sorry JohnC and crew, but wow...I'm put back in anticipation of what may be to come from the quantity of declared participants. So tally-ho, everyone in on the ride. I'm going the raycaster route to stay more in key, with an old wolfenstein clone framework from an early gameinstitute.com, Perlin Noise and AI Seminar offerings by Author : JohnDeGoes(12-15 years ago). One of the graphics items Doom brought to the table were textures on the ceiling and floor. A concept my chosen framework is unaware. This go, I'd like to do a proper AI agent type or two. Also on the todo list is a simple sprite animation atlas tool that is feed from targeted screen grab so I can render the art instead of doing pixel art or photo persuasion, but mostly hand packing image sequences is such a chore. I'd like to open this project up to others. Right now I'm thinking heavy guitar loops for game play. It would be nice to have a sound guy of the programmer persuasion and an ai guy. Lets talk. ...but after kicking the can for more than a while, the flame piddled out. I've had this project collecting dust for a decade and thought it would be a good idea to start from wolfenstein to transition to doom. Then I was umm...whatever, I've done enough 2D...moving onward. Here I'm showing the abandoning and rebirth starting with a nice modular wall asset gem from the unity store and a first stab at some licks. Makes me happy.
  • 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!