Nypyren

Members
  • Content count

    4809
  • Joined

  • Last visited

  • Days Won

    1

Nypyren last won the day on November 26

Nypyren had the most liked content!

Community Reputation

12103 Excellent

2 Followers

About Nypyren

  • Rank
    Contributor

Personal Information

  • Interests
    Programming
  1. Manual syntax trees

    Maybe overload the operators on the Expression type itself (or a type specific to performing AST generation) to make the combined expression. Then the C++ parser itself will construct your AST creation calls properly due to operator precedence rules. Also it might be worth investing time in seeing whether your 'entries' can be immutable. If so, you won't need to clone() them.
  2. Token representation

    Your lexer should be a DFA built out of switch-on-character statements and state variable(s), so your tokens should be "stored" spread out across case statement character constants in certain states. Each token you recognize should have two parts - the token type ID (integer) and possibly the substring that you parsed which resulted in this token type which you then use as a value (string, enum, integer, etc). Your lexer should then pass those tokens to your parsing engine (SLR/LR/whatever) - or the parsing engine can have a loop that calls "GetNextToken". The parsing engine should primarily be dealing with the token type IDs to guide its state(s), but if you have something like a math expression evaluator you can immediately evaluate subexpressions in the middle of the parse instead of generating an AST if you want to. But if you're not writing a high performance parser it really doesn't matter what you do. Since you're even asking this question at all implies you do care, though.
  3. Aspire ES 15 - did you get one with a 1TB 5400rpm hard drive? That might be what's slow, especially if there's a lot of disk activity. Check that in Resource Monitor. Consider upgrading to an SSD if you can afford it and if the laptop supports it. Absolutely check all activity in Resource Monitor. If there's some preinstalled crap on it you will be able to see that show up and you should uninstall anything that can't play nicely with the rest of the computer. This usually includes virus scanners. Another random thing to check: Do you have any kind of full-disk-encryption software running? BitLocker or anything like that? If so, you could try disabling that as well.
  4. That's not very much information to work with. You need to diagnose the issue. Run 'Resource Monitor' and watch what is using CPU, disk, network. See if there's anything obviously hogging resources. Perhaps you are running out of physical RAM? Performance usually drops off a cliff if that happens. Run 'View reliability history' and see how many errors/warnings/installations have happened recently. On the 5th, I got some Windows Updates, so your computer might be dealing with those. You might have missing drivers. Find and install them. Main things to check for severe performance issues are motherboard chipset drivers and GPU drivers. You might have a hardware problem (the hard drive is most likely for your symptoms if no software ends up being responsible). Search the internet to see if you can find tools for testing your hardware. There are usually tools that can test each dedicated piece of hardware for their performance. Try those. Your BIOS might need to be updated, but it's unlikely if this is a new computer. If you have an SSD, check what kind it is and look for reports about performance or stability problems. Check to see if your virus scanner is doing a full disk scan. If you're using Kaspersky, get rid of that shit immediately as it will bring your computer to its knees when it's doing a full scan. I'd just like to interject for a moment. What you’re referring to as Linux, is in fact, GNU/Linux, or as I’ve recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called “Linux”, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project. There really is a Linux, and these people are using it, but it is just a part of the system they use.Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called “Linux” distributions are really distributions of GNU/Linux.
  5. It's possible the compiler may have changed that constant to a float ahead of time (because otherwise it would have to make some assembly that converts it at runtime)
  6. My experience is: TDD slows you down because you spend time up front writing your test, then writing your code, then testing, then fixing, etc. TDD slows you down because when you want to change how something behaves to implement a new feature, you will probably break existing tests and need to fix them. This is where my "shoot yourself in the foot" comment stems from. The first major set of code I attempted to use TDD style was actually a retrofit of code without any unit tests. So my "unit" tests actually test FAR too much per test. I change one thing and I break 50 tests. This is bad! This is not how TDD should work! Tests should not overlap, so the fewest number of tests should fail per change you make, so you can either figure out if you introduced a bug, or you forgot to update the test to reflect the new behavior. TDD DRAMATICALLY helps you get code right the first time and reduces time wasted manually testing (i.e. paying a QA team to waste their time testing stuff you can test automatically with no human salary involved). Really good programmers can often get code right the first time without TDD, but I have had people break my code countless times so I'm learning that it doesn't matter how good I am at programming if I'm not the only person on the team. I'm hoping that I can introduce TDD at work to prevent code from being eroded over time. (In My Opinion) Retrofitting unit tests into code that you wrote before TDD is what causes cumbersome interfaces, which led to the development of dependency injection frameworks. If you start with TDD you should be able to avoid writing code with interfaces that are too complex to test using simple tests and too complex to initialize easily. I may change my mind about dependency injection frameworks later after I use TDD more but for now I don't like them because they feel like one giant code smell to me.
  7. Try out TDD, but beware that it has a larger learning curve than it initially seems to. You will most likely do things in a cumbersome way for a while as you get used to it, and you'll most likely shoot yourself in the foot a few times with it like I have. Try to avoid dependency injection frameworks. They're just one more thing that can go wrong. It's likely that you will be able to use TDD in a way that does not require dependency injection frameworks at all. If you get to the point where you're methodically using TDD style you will be building your program bottom-up and can avoid unwanted coupling from the start. Make things simple. Single responsibility principle is extremely important. Don't try to make everything an interface to appease the mythical DI gods; usually one function that does exactly what you want to do is the only one that ever needs to fulfill that interface. For Unity, attempt to write as much of your code as possible OUTSIDE of MonoBehaviours. MonoBehaviours have unwanted dependencies and horrid initialization restrictions compared to plain old C# classes. It's easier to test code if it doesn't require MonoBehaviour/GameObject baggage.
  8. As far as I can tell, it batches up a handful of C++ files, then generates code for that batch all at once. But the batch size is limited, so you see more Generating Code the larger the project is. Nothing's going wrong.
  9. Best practice for passing data in C#?

    Basically what cjmarsh said. Use the standard System.Collections.Generic collections (List, Stack, Queue, Dictionary, HashSet) for most things and only make a custom collection if it has some special behavior you need. You probably won't need any other collections for a long time. The main container class I can think of that I've written myself is a priority queue for A*. However, since I remember posting a reply in your thread about RPG stats (comparing dictionaries to classes-with-fields), I want to make sure we're on the same page: When we say 'custom container class' we mean a type that's specifically meant to contain data (usually all of the same type), without the container caring about the semantics of any element (i.e. the Dictionary doesn't know that it's containing RPG stats; it just sees keys and values and doesn't care what they mean). Usually every element in a container is treated the same way by the container's code. In your thread about RPG stats, the suggestion I made about having each stat as a field in a class would NOT be considered a 'container' class. Each field in a class like that has a specific meaning and is treated differently by the program. Usually you can identify when something is a container class or not by if it has some of these typical functions: Add, Remove, Insert, Push, Pop, Peek, Enqueue, Dequeue, or a square-bracket indexer. If it just has a bunch of fields that you can directly get or set then we don't typically call those containers.
  10. C# SFML and fast pixel drawing in C#

    See those massive 'new <huge array>' operations in the middle of your Update loop? Remove those. Those allocations are going to be causing GC collections too frequently. They're also going to be automatically filling the entire array with zeroes which you don't need since you immediately fill them yourself. The part where you clear ScreenBuffer to black is eating a bunch of time. In old programs, instead of clearing the screen and redrawing everything, we would update only the parts of the image that were changing. Your line moves, so the old-school technique would be to 'erase' ONLY the pixels where the line was last time only, instead of setting the entire screen black first. For mouse cursors in old apps, what I would do was save a backup copy of all of the pixels underneath where I was about to render the mouse cursor, then render the cursor, then on the next frame render the backup pixels to 'undo' rendering the mouse. You have two full-array copy loops (ScreenBuffer -> cpixels, cpixels -> pixels), but you only need one ScreenBuffer -> pixels). Get rid of the cpixels array as well. In fact you should probably get rid of ScreenBuffer and only use pixels. Just write to pixels and nothing else. You will have to know which bytes are red/green/blue/etc but you want high performance so you've gotta remove as many "worthless" operations as possible to get it fast. If SFML allows you to use uint[] instead of byte[], one assignment to a uint will be faster than four assignments to bytes. This can be useful as one uint will be one pixel anyway. C# *should* know how to optimize the constant subexpressions within inner loops such as (y*640) but you can try hand optimizing them yourself to see if it makes any difference. Make sure you are allowing JIT to fully optimize your code. If you're using Visual Studio this means using the Release configuration (or enabling optimization on the debug configuration) as well as {launching without the debugger attached or disabling Tools -> Options -> Debugging -> Suppress JIT optimization on module load}.
  11. C# Concepts Useful For JRPGs?

    For general code structure, since you're still learning, don't try to get too complex. Do the simplest thing that you think might work, and only make it more complex if you need to. For a turn based game, the simplest things you NEED are a way to keep track of whose turn it is (one variable?), having a way to perform some action(s) during a turn (something which gets input from a player or an NPC), and how/when to go to the next turn. The main suggestion I have for any new programmer is: Try to keep every function very short and simple. If you need to make something complicated, split it up into simpler parts. Turn each simple part into a function, then you can make your more complicated function by just calling the simple ones. There is a tendency to do the same kinds of things in multiple places in a game; you should try to make simple functions so that you can reuse it instead of copy-and-pasting the same code in multiple places. Always make sure to test your code frequently! Even experts make silly mistakes and it's best to catch them early. You can also automate this testing process. If you want to jump right in, look up: "Unit testing" (Unity has built-in support for these as well!) and "Test Driven Development". This stuff is somewhat separate from C#, kind of like how knowing how to use a debugger is separate. Just like knowing how to use a debugger, knowing how to use unit testing can make profound improvements to your development experience.
  12. C# Concepts Useful For JRPGs?

    RPG stats seem like you would always know what all of the stat keys are ahead of time, and every character would have a value for every stat. I would use a class containing one field per stat. Differences between the two approaches: The elements you add to a Dictionary<K,V> have to share a common base type (K for keys, V for values), and if you are using derived classes you'll have to know which type to cast to each time you access one of them. With fields you can make each field any type you want. Perhaps your stats are all ints or floats right now, but later you might want one stat to be something different. You can much more easily access a field than a Dictionary entry. You have IDE autocompletion for the field name. With a Dictionary the key might or might not exist in the Dictionary. With Dictionary keys you have at least one GetHashCode and one or more Equals calls that occur on every key lookup and member fields just use some basic pointer math which will always be faster. You can foreach over a Dictionary much more easily than member fields, though I can't think of a case where I would want to loop over stats. If you need to loop over member fields you can use a function that uses 'yield' to return a set that you can loop over. Unless your Dictionary uses an enum type for its key, you will be able to find code using one specific stat more easily with fields. If your Dictionary uses strings for its key, change that to an enum immediately even if you don't want any of the other advantages of fields listed above.
  13. DX12 Android Online Game Bot !?!Help!?!

    Typically when cheating in a Windows game (ex: CheatEngine), the way to go about it is to attach to the process with a debugger (or any other tool that can read memory from the process), look at an integer value on the UI and search for that value in the process memory. You'll find potentially thousands of memory locations due to the value probably not being very unique, and a lot of memory available. Then you perform an action in the game that you know can change that value, and search again. If the memory has not been re-allocated in the meantime you will likely narrow down the memory address for the variable you're interested in. That's usually fairly easy for integer values or strings. It's harder (and slower) for floating point values, or values that you aren't sure of their representation in memory. This also fails for Java and C# if they are using a relocating garbage collector (some mobile GC implementations disable relocation for performance, some keep it on to minimize fragmentation problems); it will depend on how the game was made. Depending on how the game developers implement resource tiles, map tiles could be an array of tile data, an array of REFERENCES to tile data, or even just a slipshod list of game objects and components in Unity that has no simple and easy-to-manipulate representation in RAM. At this point it starts heavily depending on how the game is implemented; what language or engine they used, etc. If they used Unity, their code is in C# and you can probably decompile it from the Assembly-CSharp.dll inside the APK, unless they obfuscated it (in C#'s case that would mean renaming all classes and variables to meaningless things like "A" instead of "TileMap". If it's written in Java, it's about the same effort and results. If it's C++ or Unity with IL2CPP then you will have to learn how to be a professional assembly-level reverse engineer to get anything useful out of it. If you aren't already, we're talking about multiple years worth of effort trying to learn how to do it. If you luck out and it's unobfuscated C# or Java, your best bet is to modify that code directly to do what you need. For Unity APKs which do not use IL2CPP, the .Net DLLs will be present and you should be able to edit them to a certain extent using dnSpy. Unity does make some tweaks to these DLLs itself in order for prefab->script references to find and instantiate the proper classes (and other things like that), so there's a risk that you can break the game completely if you attempt this; I've only modified XNA games for Windows this way, personally. For Java, I only know of jdGUI for decompiling code; I haven't found anything like dnSpy for Java yet. For native code (compiled from C++ or IL2CPP) you will need a professional grade disassembler/decompiler such as IDA Pro. IDA Pro has a free version of their disassembler that will work on the x86 binaries that should be present in Android APKs (Android native code should normally include both ARMv7 and x86 native code since some Androids use x86. Most use ARM, which I don't believe is freely available in IDA's free version. Their decompiler is not free and will likely be far outside of your budget. Remember that if you modify the x86 binary you will have to run the modified version on an x86 processor, which likely means using the emulator since the vast majority of Android devices use ARM. After that you have to figure out how to reconstruct an APK from your modified files and install it on your device. If the game has any security measures which try to validate its signature, you will have to find and defeat those during the modification step. I haven't done this myself so I'm not sure of what you might encounter.
  14. DX12 Android Online Game Bot !?!Help!?!

    Possibly. It's possible you could inject a DLL into the emulator, but my gut feeling is that it would be even harder to find what you're interested in. If you have an emulator you could possibly automate what you want at the UI level (i.e. make a program that simulates clicking on the emulator's screen at the right places). It sounds like Kevin is talking about a similar tool that will run on the Android device itself, but I can't read Chinese so I'm not sure what any of those youtube tutorials say.
  15. DX12 Android Online Game Bot !?!Help!?!

    Not for Android, no. DLL Injection is strictly for Windows programs. I don't know how feasible it is for you, but you can probably get the APK off your device using adb (not sure about this). APK files are just zip files, so extract it. Then it will depend on how the program was written. If it's C++, you'll have to get good reading assembly. If it's Java, you can use a Java decompiler on it. If it's C# then you can use a C# decompiler on it. I do this at work to analyze the APKs we create before we publish them to make sure we're not wasting space on anything stupid. After that, it's pretty much up to you to figure out how to find what you want to automate and put it back together into a working APK. I've never done that. It's also unlikely that a decompiler will give you something that you can actually compile again. You also will not be able to sign the APK using the original signature, but you will probably be able to sign it yourself as long as nothing bothers to validate the signature. If that fails, your next option (if it's a properly constructed client/server game) is to intercept the network traffic and automate the request/responses using a standalone program that you create from scratch. This will only work if the game and server are not using SSL in a way that prevents proxy interception (and I know from experience that a lot of games do not bother).