• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

9581 Excellent


About Alberth

  • Rank

Personal Information

  • Interests
  1. an early coding exercise 1

    An alternative is to use format(): print("and tax: ${} comes to ${}".format(tax, totalcarPrice)) Write the string as you want it, with "{}" at places where you want a number. Then add ".format(<values>)" behind the string. The format method creates a new string from your template by finding each "{}", and replacing it by a value listed in the format arguments. Format can do more, but this will suffice at first
  2. The simple way around that is to walk "backwards". On an iteration where you expand from node A to say neighbours B1, and B2, check whether you can move from B* to A (instead of the usual A to B*), and take the cost also in the opposite direction, if that matters.
  3. C# Peek through door

    replace the normal door by a peekable-only door?
  4. Python Interest in Python

    As Python (but eg Lua too) is a dynamic language, it's quite impossible to decide on semantics of some code until runtime. Checkers can catch a few things but not everything. If you still want linters, there is pylint (https://www.pylint.org/) which is mostly checking PEP8, the defacto-standard code style. There is also pyflakes (https://pypi.python.org/pypi/pyflakes) which is more oriented to finding real errors. pypi.python.org is btw a useful resource for random packages that you might need, pretty much anything you need already exists.
  5. How to make 8-bit sprites out of 16 or 32-bit ones?

    There is a visual art forum, you may want to try it there. While beginners forum is for anything, almost all questions here are related to programming, and most readers are programmers. Together with a confusing question about bith depths of images, we (in hindsight incorrectly) considered your question to be a programming question about image formats rather than "make it look like a retro image".
  6. Organization and prioritizing

    Listing all wishes is easy, but it may become too long to be realistic. One tactic to tackle that is to start with the absolute minimum that you need for a tiny version of the game. Try to delay non-essentials as much as you can, then try again to do that a few days later, if it works, try again a little later. You'll be amazed at how little you really really really need to make a game. Obviously it won't be feature complete, and missing a load of stuff, but the game becomes faster to make, and reach the playing point. Once you get there, play the game, and decide how to expand a tiny amount to make it better. Repeat until you've had enough, think you're done, or have run out of ideas or time. (Whatever comes first )
  7. What you may be missing is that not all pixels are of equal size. 4K monitors have more dense pixels, ie each pixel is smaller so you get more pixels/inch. To get the same size images displayed (in inches of used screen size), the images must use more pixels, ie be bigger in x and y size. The idea is that more pixels/inch means you can show more smaller details, eg anti-aliasing of text becomes better.
  8. Simple advice for a beginner game-developer

    C++ is fundamentally different from Java. Its aim is to enable you to get the best possible performance out of your system. It does that by giving you complete control of execution and memory. Java on the other hand aims to simplify programming as much as possible, it does that by taking away choices as much as possible. The result is that using C++ can give a much faster execution, since a JVM is never as smart as a smart developer. From a Java perspective, your playing table has become much much larger, so indeed, it's hard if you find your world is a lot bigger than you ever imagined possible. In my experience, when learning something new, don't try to relate it to something you already know. Try to forget everything you already know, and take the new thing starting from a blank sheet. In your situation, this holds even more, C++ is "bigger", it puts more cards onto the table. It's impossible to relate all those cards to the cards you have from Java knowledge, as there are C++ cards that are totally new, there is eg nothing in Java relates to "memory management" or "pointers" from C++. If you take C++ from a blank sheet, you'll notice that the language is much more systematic, it just gives you all cards, and you can decide which cards you want to use (Java makes a lot of decisions for you there). For example, you have value variables for all types (Java only has the basic types as value type), you have reference variables for all types (Java only has objects as reference types), you have pointers for all types (don't exist at all in Java), templates work with all types (generics only work 1 level deep, and fail with arrays in Java). So there are more cards, but there are less exceptions. Once you mostly understand how C++ work, you can faithfully try to relate Java and C++ to each other, and make up your mind how one relates to the other. To me, Java is the little nanny sister of C++, but ymmv. What you get in any case, is a deeper understanding of how a computer actually works. (C++ is hiding very little there.) That understanding will be beneficial to anything that you might do in the future. As for your other considerations, C# is much closer to Java, so likely you'll have an easier time learning that. On the other hand, it has evolved much more rapidly than Java in the past decades, and also has many new features, as well as concepts that are traditionally found in languages like C++. Game engines are pretty much tied to a single programming language (as they are basically large frame works written in that language). Unity is tightly connected with C#, and Unreal with C++.
  9. How to make 8-bit sprites out of 16 or 32-bit ones?

    I still am much confused what problem you are trying to solve here. To eliminate the confusion, please only talk about the image, and not about systems that may display it. An image has a size in pixels (in 2 directions), and each pixel has a colour, usually in 3 or 4 channels (normally RGB and an A channel for opaqness). Each channel has a bit depth (number of bits available to express the fraction of eg Red). Further limitations may be that only a limited number of unique RGB combinations may be used (eg gif has 256 colours available from the 24bit RGB space), or that the set of available RGB combinations is fixed (eg the system has already fixed the palette). EDIT: For valid sizes, you may want to use cropped image sizes, eg not the large white area that you have in some of the examples, as that is non-relevant to the problem. Since you mostly excluded reduction in colours from the question, I assume you are talking about a reduction in size. You can map several pixels from the source image onto one pixel in the destination, by blending their colours. As an example, converting an image from 10x1 to 5x1 can be done by blending the colours of the first two pixels into the first pixel of the destination, the colours of the 3rd and 4th pixel into the 2nd pixel at the destination, and so on. The reduction doesn't have to be a power of 2, if you go from 10 pixels to 6 pixels, each pixel in the destination gets 10/6th pixels from the source, using a weighted average, for example. Enlarging is the same process, except you'll very little colour information available. None of these automated techniques will give you good quality images. The computer doesn't understand that one line has more importance than a filled area near to it, for example. In any case, you'll need to improve, or even redraw the images, if you want good quality.
  10. Continue with library or move on to engine?

    Danger is perhaps a bit overestimating, I see them mostly as enrichment. If you are a carpenter, and you only know about hammers, then the entire world is a nail. By learning about saws and screw drivers, you expand your knowledge, you become a better carpenter. Switching from hammer to saw is however quite daunting, you have to let go of all your hammer ideas, and use a saw as it was designed to be used from the ground up, ie using a saw in a hammer-like way won't give you very satisfactory results. Give each tool a fair chance to shine. Once you understand how a saw is to be used as a saw, you can work on using a hammer and a saw together, picking the right tool at each stage. At this point you can understand which tool to use for which job, and you know what you're going to be missing if you pick a different tool instead (which can happen for various reasons). A little further, maybe you can tweak one tool a bit in the direction of that missing tool, and simplify you problem a bit. Basically, use good stuff from one tool in context of another tool. Your idea of also concentrating on depth is a good one, algorithms and data structures are useful everywhere.
  11. Users may not like an AI that is so cunning
  12. Being able to generate a digital signature may prove he has the data, but it does not mean he is actually using that data, or that he is using your program, for that matter.
  13. Continue with library or move on to engine?

    Since eventually, everything is put onto the same von Neumann machine, most "depth" is universally applicable. classes and objects work in much the same way everywhere, with the same kind of design issues. Algorithms are language-independent, and all languages have the same kind of data structures. That makes "programming" pretty much transferable across different language without major efforts. (Well, until you go into more exotic languages, like Prolog, Lisp, or a functional language :)) "breath" is more hazardous however. Lots of things look the same at the surface (while loop and assignment look the same everywhere), but are in fact very different when you dig deeper, and work with the language or the tool. These differences make one tool or language more useful for a particular type of problems. I find the differences enlightening. Most languages and tools tell you a certain practice without explaining why. By trying several different practices, you experience that other solutions work too, solutions that you can apply in other situations too.
  14. If you have a regular grid, and a finite distance, you can build a static map of feasible rays. A ray going 5 tiles north goes through the same set of tiles if you look relative to the starting point. Thus if you store those 5 tiles, you can just check their content rather than computing all the rays. That is, it's a re-usable template of tiles that you visit relative to your starting point rather than a unique set of rays from each position. Obviously walls become occupied tiles now, as the pattern doesn't have walls. Secondly, if you hit a blockade at some tile, that blockade will be there as well for a ray the goes in almost the same direction. That is, one blockade hits a lot of rays that you can skip even trying. Each blockade disables a set of rays. Assuming you have a sparse number of enemy tiles being used, you can also do this in reverse. From a given relative tile, you know which rays will go to that tile, so to test if you can hit that enemy, you only need to check those rays.
  15. Standard data base access is SQL. Find a database library for your language, and do its tutorial. Common pattern is that you execute an SQL statement and then have a loop in your programming language where to write or read records.
  • Advertisement