Jump to content
  • Advertisement

Zakwayda

Member
  • Content Count

    12855
  • Joined

  • Last visited

  • Days Won

    7

Zakwayda last won the day on September 16

Zakwayda had the most liked content!

Community Reputation

2323 Excellent

3 Followers

About Zakwayda

  • Rank
    GDNet+

Personal Information

  • Interests
    Programming

Recent Profile Visitors

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

  1. Apologies if the answer to this is obvious, but is the idea that the objects store texture reference objects by value, and the texture objects reference their associated texture reference objects by pointer or reference? (Maybe I'm misunderstanding, but it seems like that would have to be the case in order to get the contiguousness you seem to be after.)
  2. Zakwayda

    fill fixed byte with values

    Apologies if I'm missing the obvious, but can you just write and read the ints/floats/etc. in sequence? (One of the threads I linked to suggests serializing vectors in this way.)
  3. Zakwayda

    fill fixed byte with values

    I don't know the answer, as I'm not up to date with Unity and am not sure what features are available there. I did find a couple threads that might (or might not) be relevant (the information may be out of date though - the threads are a few years old): 1 2 Also, it sounds like you've already figured out how to serialize integers (which I assume doesn't mean only bytes). How are you doing that? It seems like the solution for other types (e.g. floats) could be related.
  4. This is all just low-hanging fruit based on a quick look at some of the code (some of the things pointed out here come up pretty commonly in code review requests): - In C++, the use of the preprocessor for constants is generally discouraged for various reasons (at or towards the top of that list would probably be that preprocessor macros are scope-unaware). C++ provides (arguably) better tools for this, such as 'const' and 'constexpr'. - Very minor, but I'd suggest expressing the 'degree to radians' constant in terms of pi (e.g. 'pi / 180.0') rather than expressing it as a literal. Since it's dependent on a constant you've already defined, there may be no particular reason to express it directly (which, among other things, runs the risk of getting it wrong). Technically you could probably also get pi from a trig function, although that's probably less important. (Although the chances of getting these constants wrong is obviously low, the general goal here is to minimize the number of hard-coded values - especially values that have invariant relationships to one another - and therefore reduce the potential for error.) - It's idiomatic to pass instances of non-trivial types like std::string by reference (constant reference if mutability isn't required, which I would think is usually the case), which may avoid some overhead. - How much to use 'const' is a matter of taste and opinion, but if you want (this is my preference), there are some things you can or might be able to make constant that aren't currently (e.g. immutable function arguments, member fields, locals, etc.). - In the 'Game' class, you're creating and deleting m_GameSceneManager manually, but it would probably be safer and more idiomatic to use e.g. std::unique_ptr for this. Among other things, this would remove the need for deleting it explicitly in the destructor and elsewhere. - '#pragma once' is widely supported, but technically non-standard. Just something to be aware of, depending on what your portability goals are. - Here: if (m_GameSceneManager == nullptr) m_GameSceneManager = ...; You have a control structure without braces. Opinions may differ on this, but it's often recommended to always include the braces (one reason being that if you decide to add additional statements later, you won't run the risk of introducing bugs by forgetting to add the braces, and also won't have to go to the trouble of adding them after the fact at all). - Just as a point of interest, 'return 0' in main() is the default behavior, so its inclusion is optional. I suppose some might recommend including it for clarity regardless (as you're doing). There are probably some other things, but I didn't look at all the code, and in any case that's probably enough for one post. Overall it looks very good
  5. Your original post was a bit hard to parse for me, so maybe I didn't understand what you meant. My only thought at the moment is that maybe it's the translations in the 'if' statements that need to be in a different space - local instead of global in this case. In other words, you could try using Transform.Translate() there (using the 'local space' option, implicitly or explicitly) instead of modifying the position directly. Again though, there are some things in your code that don't make immediate sense to me, so I'm guessing a bit here. [Edit: Upon reflection, it does seem like maybe you intended for those corrective translations to be local rather than global. That would seem to make a certain amount of sense given what you've written.]
  6. There are some aspects of the code I'm not quite clear on, but I'll make one observation. Here: transform.Translate(0, moveVertical * speed * Time.deltaTime, 0); You're using an overload of Transform.Translate() that assumes local space (as I suspected). Try using an overload that allows you to specify the space, and specify world space. (Or you could just modify the position directly, which you're doing elsewhere anyway.)
  7. This sounds like more of a programming question than an art question. In any case, what you describe sounds like the object is being moved along a local axis rather than along the global x axis, but we'd probably need to see some code to be sure. So, maybe you could post the bit of code that moves the object.
  8. Zakwayda

    Sprite batching problem

    Maybe the error is obvious in what you've posted, but it's more than I'm up to analyzing right now. Maybe someone else will jump in, but meanwhile I'll offer some more advice. Try calling glGetError(), if you're not already doing so, in order to catch any obvious errors. I also noticed you're negating the texture coordinate y values - you might double-check that that's what you want and that your texture parameters are set up appropriately for it. (Although unless your texture has some white in it, it seems more likely that texturing isn't working at all.) Did you set the sampler2D uniform? Anyway, this is a good exercise in debugging, I think. You said you successfully implemented rendering a single textured quad, so obviously there's some disconnect between that code and your current code - some step you've left out or something you've done differently. I'd suggest a careful analysis and comparison (perhaps just rendering a single sprite rather than many for the time being) to try to find where the disconnect is. I'll have to leave it there for now, but maybe something there will help get you pointed in the right direction.
  9. Zakwayda

    Sprite batching problem

    I see. That's a fair amount of code to look through, but irrespective of that, I think there's code missing that we'd have to see anyway. For example, I don't see anything having to do with program or texture creation or setup (presumably that happens elsewhere). In any case, there's probably little point in implementing something like sprite batching until you get the basics working. So, what I'd recommend is to write the simplest program you can that renders a single textured quad. There are plenty of tutorials that cover that material, so it should be fairly easy to find step-by-step instructions that will cover all the necessary steps. Once you have that working, you can move back to what you're doing currently, and if you find things aren't working, you can refer back to the simple example to see if you've missed anything, and/or post back here with your revised code.
  10. Zakwayda

    Sprite batching problem

    If you're on a deadline of some sort, a discussion forum might not be the best way to resolve your issue. Just to be safe, let me ask, is this for homework of some sort?
  11. Zakwayda

    Sprite batching problem

    It's likely that someone can help you solve the problem, but could you paste your code into a post so that it's easier to examine?
  12. Glad to hear you were able to get it working 🙂
  13. There's more there than I can easily sort out, but I'll point out one thing. XMVector3Transform() treats the input vector as a point (with w = 1), which probably isn't what you want for the direction vector. XMVector3TransformNormal() may do what you want there (in other words, use XMVector3Transform() for the origin and XMVector3TransformNormal() for the direction). I suspect that may be an issue, but it may not be the only issue. There are many places that picking or raycasting (or any similarly complex geometric algorithm) can go awry, and there could easily be other issues at play here. But, I'd at least give the XMVector3Transform()/XMVector3TransformNormal() suggestion a try. I can think of some other things that might make it easier to get this sorted out, but I'll refrain from offering them unless asked, as they're somewhat tangential and may not constitute the kind of feedback you're interested in.
  14. When you refer to only working at the origin, I'm not sure if you mean it only works when the ray originates at the origin, or when the model is positioned at the origin. In any case, in TestOBBIntersection(), you don't appear to be factoring in the model position, which seems like it could be related. Also, I don't know the details of the math library you're using, but keep in mind the distinction between positions and vectors when applying transforms.
  15. Zakwayda

    2.5d game vs 3d game

    I could be wrong, but I'm not sure 2.5d necessarily means 2-d with 3-d shaders (assuming by 3-d shaders you mean programmable pipelines in APIs like OpenGL and Direct3D). I Googled the term, and it seems to mean different things, with the meaning perhaps having changed over time. I remember it being used to describe 3-d games with 2-d sprites and various spatial limitations, like Doom and Marathon, but the usage seems to be different now. In any case, if this is your first project, I'd recommend starting with a simple 2-d game. There will be plenty of challenges entailed in that even without adding extra dimensions (or half-dimensions 🙂).
  • 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!