Advertisement Jump to content
  • Advertisement

ninnghazad

Member
  • Content Count

    89
  • Joined

  • Last visited

Community Reputation

475 Neutral

About ninnghazad

  • Rank
    Member

Personal Information

  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. As JoeJ said, use GPU-supported formats for production builds. Some resources: OpenGL Wiki on Texture Compression Nvidia Texture Tools
  2. the number of unique vertices per triangle per level of subdivision (not per hex) should be integer sequence https://oeis.org/A028401 btw: if all triangles are supposed to have the same depth of subdivision, don't use pointers - just use a flat array and calculate indices.
  3. Extendable prototypes are useful - Enemy->Undead->Skeleton for example. Just to not have to write so much. Using combining prototypes may be useful, but also kind of doubles the whole component thing - might well be superfluous. Creating entities from prototypes does not mandate passing parameters to whatever actually creates them. At whatever point you create an entity, you know why and what entity is to be created. You might as well just return one from the factory without passing anything other than the proto-id, and set whatever you need on the returned entity in whatever place requested it. Lets say you populate a dungeon with enemies - that generator-thing knows "right now i wanna place a skelly at X,Y" - so have it request a skeleton and have it set the proper position. If you have serialization for your entities, human readable that is (so you can manually adjust the file), you could just use that for "prototypes". create an "empty" skeleton, save it, and use that when somebody request a fresh skeleton. Another way might be to have prototypes and init-data, prototypes have an init-function that accepts init-data to set up that specific type of entity. So you can decouple specific inits away from the factory to some place more appropriate.
  4. Ye, you send a prepared sparse octree, basically an array of the tree's nodes. you can use vertex shader to do some translations and then use the fragment shader to raytrace it. or you use OpenCL/CUDA for the actual tracing, but fragment shaders would do. a sparse tree uses (in most cases) a lot less data than the raw data, on top of that you have kind of builtin multisampling for far away nodes. i advise to read this excellent paper from NVIDIA on the subject: https://www.nvidia.com/docs/IO/88889/laine2010i3d_paper.pdf also if you do not need transparency (which i would assume you don't with medical scans) you can raytrace front to back and stop at first hit. and if you only need to see the surface and not be able to dynamically slice the scan, you can store only the surface in the octree, drastically reducing its size. for a simple introduction check out this cpu-only example: https://github.com/tunabrain/sparse-voxel-octrees should you find that SVOs aren't for you, consider using multiple compressed 3d-textures. you prepare each "cube" by quantizing non-surface areas of the scan. this will let the compression achieve better ratios without reducing the visual niceness too much.
  5. I assume you are not going to dynamically change the scanned data - in that case you might want to consider pre-processing you image data into some (sparse) octree. That works well with raytracing. You'd then upload that octree as a non-image-blob or an array of 3d-textures (blob is easier for starts) and traverse it in your shaders. That has some nice benefits - like you can get kind of a cone-tracing thing for free and traversal can be (depending on the data) a lot faster. You could even do marching-cubes on the octree to get some nice normals for shading. And you can easily save that preprocessed octree to a file so your program does not have to parse all images on each startup. I found that i actually *had* to use data structures like that because large scans don't fit onto reasonable gpus, and with a nice tree you can quantize the data a little and gain some nice "compression"-ratios on the way.
  6. As for unordered_map, check out https://github.com/greg7mdp/sparsepp - works as a drop-in replacement and is quite fast. Another thing you should mention on the main page how this behaves with multiple threads and how it allocates its memory. Is it ye 'ol queue from everywhere but process in one place? lockless/mutexes/blocking/whatever? Can i give it custom allocators or make it use some kind of fancy pool/freelist/whatever allocation?
  7. you could use lower resolution terrain and bounding-box-only collision for the server and allow an error of like 5cm. also limit player speed to like 10m/s, which is about as fast as humans can possibly go. on the client there is no point in just loading 9 chunks per player - if players' chunks aren't connected, loading them would look silly. maybe do like minecraft does and just keep loading chunks until you reach max-draw-distance, but prioritize chunks near players. for AI i'd generate a simplified path-map per chunk. take care with the transitions between chunks though. you could use that for player checking on the server-side too.
  8. Ah yes... i put off implementing "object delete" messages thinking "ah, just let them timeout" or something. which was stupid. those were rather easy to implement, they get spammed until ACK, then all ACKed entities are removed from the set. these partly solve my problem already. once one of those arrives, i can be sure there will be no more updates that might in any way depend on the removed entity. (except for some heavy out-of-order arrival, but can't have it all) that leaves a window of ping/2 in which a problematic update might arrive. for now i put entities in a zombie-state on the client and truly destroy them once the "object delete" arrives. in zombie-state i can revive entities for rollbacks, during which they will ofc get killed again. poor entities. i have brainfood for now to go on and solve my initial issue. still thinking about the rollback-system as a whole, re-reading gaffer's and the valve-docs for the Nth time - but i guess that's another thread. thanks Kylotan and hplus0603 for your input.
  9. Thanks for you input. Hm... no rollback-stuff... that would be nice, because that is ... rather complicated - and grows evermore so. The physics aren't deterministic and updates arriving are ofc from the past. Hm. I remember trying to not resimulate but just calculate corrections against past position/vel/accel and applying delta in the present. It looked off unless i used a high rate of updates and went with just a little latency. But a little prediction/extrapolation of these delta might improve that... However applying other state like logic, health or other scripted state might get messy without proper resimulation. Will have to think about that some more. By your first point - do you mean entities from each other, or received states from local states? Sounds like both kind of. But because of the physics-sim with interacting forces i cannot see either atm. Currently the rollback-stuff EATS cpu - a high rate of updates and a very high latency means simulating each frame like 10 times over. Thats not ideal. Using lower rates of updates kind of makes it ok, and there is almost 0 difference between server and client with the resimulations - which is rather cool. except ofc for the issue above... About needing rollbacks - 2d, multiple players with gamepad-style inputs that have immediate effects, physics where world/pve-collision is more important than pvp-collision - targeting inet latency. The player is supposed to have a jump'n'run-y experience, with prompt response of his avatar and the world, where other players' actions need be visible but not necessarily fully in sync. So i *think* i need it - but your comment shall make me think about that need again.
  10. Authoritative server sends state of multiple, but not all, entities periodically. Client receives and re-simulates all entities from server's state, or locally saved states if entity is not included in update. Now imagine short-lived entities on the client. An entity is created at time 1 and destroyed at time 3. At time 4 an update arrives, with info on time 2, and the client rolls back to time 2, in order to re-simulate from time 2 to 4. The update did not include the already destroyed entity, but may include entities affected by it. There are no locally saved states for the destroyed entity anymore, because it's destroyed. The re-simulation would diverge because the destroyed entity is gone and will not be able to affect other entities in re-simulation. I am thinking of some kind of zombie-mode for entities, which wouldn't be easy to integrate to the used ECS, to keep them around for eventual revive for rollbacks/resims. Or keeping entity-states outside of entities, and recreate destroyed entities when rolling back past the time of their destruction. Or not allowing rollback past destruction, which isn't a real solution. It seems to me i cannot completely avoid this problem, and all solutions i can think of are kind of cumbersome. What to do in such a case? Surely there has to be some obvious, easy and performant solution i just did not think of ...
  11. ninnghazad

    900 Hz Monitor? would it matter?

    Are you planning to rotate around the screens center of mass? Otherwise i'd stay faaar away from an installation slinging otc screens around at like hundreds of km/h. However, i read about 480hz display controllers. Check out zisworks for the x28, 28" 580p @ 480hz they say. They also sell just the controllers i think - so you could try to build your own from the panels and controllers. Just in case that x28 separates into pieces at 1800rpm... Maybe interesting to you, these guys: https://www.blurbusters.com/4k-120hz-with-bonus-240hz-and-480hz-modes/ Bunch of nerds obsessed with trying to get high frame/refresh-rates to reduce visual blur. That's where i found that monitor btw. EDIT: also could try to put 2 or 3 of these back-to-back or in outward-facing triangle to reduce need for 900hz. would need to sync that so the screens are a frame apart. would increase G on the whole thing tho probably. EDIT2: also making rotating-adapter for 3 hdmi (or the like) cables plus power... ugh...
  12. ninnghazad

    Why A.I is impossible

    That's like saying "Aw man, I stumbled in to the outdoors again."
  13. ninnghazad

    Making games is no fun for me?

    Hm, there is a blurry line somewhere between keep-on-trying and acknowledgement of the wrong goals. maybe you're asking yourself the wrong question - why do you feel you have to prove that to yourself? if that has going on for a longer time, all you prove is that you can torture yourself over something without any tangible benefits to yourself (or to those around you). If it's not for money, you do not need to finish anything, you do not need to do it all. Certainly not if it doesn't make your life better in any way. Take a break, maybe play some games instead. If the passion comes back, so be it, if not - f* it.
  14. I think Nypyren is right, see Octree.h line 70 : WORD *indices; That smells of integer rollover.
  15. lol. no. you could've just asked - not gonna click that. and would you have asked, the answers would have probably revolved around "a*-ish, but depends on actual navigational domain."
  • 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!