Jump to content
  • Advertisement

Alberth

Member
  • Content count

    1802
  • Joined

  • Last visited

  • Days Won

    3

Alberth last won the day on July 27

Alberth had the most liked content!

Community Reputation

9669 Excellent

5 Followers

About Alberth

  • Rank
    Contributor

Personal Information

  • Role
    Programmer
  • Interests
    Programming

Recent Profile Visitors

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

  1. Without disclosing what your device is doing, it's impossible to tell, I think. If I was a modder, and some dude comes along that wants an API call for a device he does not tell me, I'd ask a high enough price so I don't have to care what the guy aims to do. "fair" comes from both sides.
  2. That adds synchronization overhead on each access to the list, which is not needed if at most one thread accesses it. Edit: Also, it's the wrong programming language you're talking about ūüėõ
  3. Alberth

    Handling player stats and skills

    I'd would argue that only the skills relevant for whatever action is being performed should be considered. Eg speeding up would only need "track-type", while cornering would need less "track-type" and more "surface skill" Each action would get additional parameters for the relevance, like speeding-up: track_relevance = 1.0 cornering: track_relevance = 0.3; surface_relevance=0.7 Together with the suggestion by @Darkstorm05, you'd get something like (track_relevance * track_skill + surface_relevance * surface_skill) * (0.5 + luck)
  4. Alberth

    Array arithmetic

    The mistake that you make is that you follow your intuition, and/or the tutorial you once read. Both say that "a[j]" "means index j into array a". While this what it effectively means, this is technically actually not true in the details of the semantics of the c++ language. In a sense, p[q] doesn't exist at all. It is just a nice looking abbreviation for *(p+q) . This rewrite doesn't care about types of p and q. As a result v[w] and w[v] mean the same thing, because *(v+w) and *(w+v) give the same answer, as you expect from + (+ is a commutative operator). In other words, the tutorial you read technically lied to you, and tricked you into believing that a[j] exists with the semantics like you believe it has. In fact, the semantics of [] are not handled by the [] operator at all, but by the +, after the above rewrite of p[q] to *(p+q). (According to the language definition, an actual compiler may do otherwise here, and eg recognize [] on its own, for example to give better error messages or so.) The T* comes into play when computing the "+" result. When you try to add a pointer and an integer together, the size of the element-type of the pointer is multiplied with the integer. a[j] -> *(a + j) -> *( ((char*)&a[0]) + sizeof(T)*j ) j[a] -> *(j + a) -> *( sizeof(T)*j + ((char*)&a[0]) ) Note that "((char*)&a[0])" is an awkward notation for "the first address in the array, and stripping away the sizeof multiplication from the addition" "sizeof(T)*j" is the offset of the j-th value in the array. Both are just numbers, and swapping them has no effect, both calculations give the same answer.
  5. A language definition doesn't describe actual implementation behavior, it describes rules that must hold for any implementation of the language. That is, an actual implementation of the language may do anything it likes, as long as all the rules in the language are fulfilled. This opens the door to optimizing the implementation. Different compilers make different choices there, resulting in differences in performance for a single program. If you write your program while following all the rules of the language, it will work correctly with any compiler. If you go beyond what the language rules promise, you're in "undefined behavior" land, which may or may not work, depending on what an implementation actually does.
  6. Alberth

    Talent Show interface? Where to start

    I would assume it's mostly full-screen static display of some text, so any video library will basically do I think. Bottom is likely a low-level library like SDL (that's C/C++, sorry don't know any C# libs for that, but they must exist). The screen is a collection of pixels, go draw on it! (more likely, make a set of images or SVG files, and display them) A little higher in functionality is something like a full-screen web-browser, which also gives you input capabilities in a GUI-like setup, out of the box. For that matter, a standard GUI application (with buttons, menu bars, and drop-downs, etc) might also work. Display is then just a window at the same size as the video display, so all edges are outside the display. A full-blown game engine will of course also work, although you won't use a large part of its functionality.
  7. Alberth

    Talent Show interface? Where to start

    Start with the various screens that you want to display to the audience I think. Make mock-ups; pen & paper could work, or a paint program or so. The screens then define what kind of information you need to have available, and from which screen you can go to what other screens etc. Next problem is then how to get the information you need to display, where does it come from, is it fixed information or decided on the spot? Who enters it? When? At what screen? Using what interface? (More screens to mock-up!) Play this game for a while, start from various points, eg each person involved, what does he/she needs to do? what does he/she see, what needs to happen with corrections, equal scores, what not. You could even make a complete script, or you do simulate things with pieces of paper being the screens, and a image or description what's on them. You could write a manual for each person. The whole point of all the above is to get clear how it works each step of the way, for everybody involved, also for the cases that don't happen often (or never). Once you understand what it needs to do, you can start thinking about building it.
  8. Don't dwell on such questions too long. The future is terribly hard to predict, in particular in an environment where ideas and requirements are constantly changing. Finish it in a nice manner, and let time decide whether it was robust.
  9. If you want to really know, check the official C++ language definition for a rule that says what must happen in these specific cases. If a compiler behaves differently than the spec allows, it is a bug. It can be perfectly fine to have two different compilers says different things about the same specification. By design, the C++ language specification gives a lot of freedom for the implementation to make their own decisions.
  10. Just write a game using low-level GPU, like OpenGL. You'll get 3D math stuff just as well, but you can make a game that's playable, rather than spend eternity with a game engine that's not done, and getting nowhere.
  11. Alberth

    UDP Confusion c++ sockets

    tcp is basically udp, but with the stuff you need to reliably send something from A to B. There are years to decades of research in tcp implementations. Systems like "the web", and "ftp sites" run on it. OSes use it for "updates". Everything real-time from RPC to chat such as IRC uses it world-wide, with a zillion users. Really, you're not going to make something better by using udp and extending it yourself to get reliability.
  12. The nice thing about algorithms is that they are self-contained solutions to a problem. In my opinion, you understand the algorithm if you can build an implementation. It doesn't have to be fast or fancy, just a basic implementation (it's math, it doesn't care about cpu speed or problem scale, it only cares about what steps and computations to perform to solve the problem). Make a relevant small example of the problem, and solve it using your code. That should give a basic understanding of how it does its thing. From there you can invent or study better implementations, which eg focus on storage size or speed or whatever is felt to be important. For path-finding, after Dijkstra, I'd suggest to do the A* algorithm as well. That should cover about 90% of all path-find problems.
  13. Alberth

    basic online interaction

    It may look basic, but it isn't, since it involves communication between computers. You may want to head over to the networking forum to discuss the communication problem. As a start, TCP/IP network communication looks feasible here (and is the simplest). At the client-side you need to handle input from the network and the user, and display something on the screen. You can do this in nearly infinitely many ways, anything from a web-browser to a full-blown game engine to a gui application to a plain console application. Also, you didn't mention what programming languages you know, although something C-ish seems likely given your path. As a first shot I'd suggest use Python, but you may want to discuss this in follow-up posts when you give your language knowledge and preferences. At the server-side (which could be a client as well of course), you have connections from all users that you have to deal with. It's simpler in the sense that there is no gui and no user input to deal with. Again, any language will do, find stuff about handling multiple network connection in your preferred language, "select" is the term to look for at unixy systems, ie select(2).
  14. It's not that simple. If you access the global data often enough, it sticks in the cache, and access is fast. Cache doesn't care about memory segments, it cares about data access patterns at memory address level. Given that you likely perform more than one read or write operation in your blob of allocated memory, I'd say focus on that rather than a single dereference jump to get to the blob. And of course, a bad algorithm to perform the computation itself dwarfs all your memory access optimizations so get that right first.
  15. I like the idea of a proxy object. Since the user has to store the pointer somewhere anyway, wrap a proxy-object around it. It has thus 1 data member, the raw pointer. Next add convenience method to it. A *() operator to make accessing the pool simpler, add a "get the raw pointer" method to it, and add a "remove/invalidate the pointer" method. Make the proxy copy-able, so a user can make copies if he/she so desires. Now you can play with being more or less paranoid vs less or more speed-conscience. In release mode, the *() operator simply forwards the pointed-to data reference, "get the pointer" gets the pointer from the pool (ie what you have to do anyway, the additional proxy dereference won't make a dent, as it doesn't happen that often), and "remove/invalidate" does nothing. Compiler optimization then does the rest, giving you near-equal (if not actually equal) performance as with a raw pointer. In debug mode you can have the proxy objects manage a reference count in the pool, or they register themselves, so you can visit them and check the pointer is invalidated, and pretty much anything else you may want. You can also have additional data in the proxy in debug mode if that helps. A change of size may however cause havoc in alignment / padding, which should be carefully considered.
  • Advertisement
√ó

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!