Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


Alberth last won the day on July 27

Alberth had the most liked content!

Community Reputation

9698 Excellent


About Alberth

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

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

  1. Yes, sure. Not all pixel programs are equal. You definitely want to select one that has all the features you want to have. You can't make a wrong choice. Editors and other programs are personal choices, for you and only you the choice has to be optimal. What all others think about your choice is irrelevant. Everybody use the programs he/she likes best, and recommends them. However, there are no two people that make the exact same choices. As such, asking around gives you a list of software that people use, but pretty much always there is no single program that does everything optimal for everybody. You have to make your own selection of programs that work best for you. You usually do that by giving them a spin (or two), and keeping what you like. Your choices do vary over time, so it's quite likely that what you pick today will be discarded tomorrow, and that's fine. You evolve (in experience and interests), software evolves (in features), and computers evolve (in hardware, as well as software). It would be weird if you never change preferred programs in your life.
  2. Alberth

    Symbol lookup error on Linux

    Source code is likely correct, you established there is a symbol not resolved that is available in the static library. (You may want to double check the name using the computer, I am at least horrible with finding minor differences between random-ish words.) More likely, there is something wrong in how you link the dynamic library. Some missing option or wrong order of options in the link command. Linking is a complicated activity, with many subtleties, that you can all express in the options. Throwing a number of libraries together, and saying "figure it out" is likely to fail at the level of complexity with mixing dynamic and static libraries. Some first thoughts that I have are that the static library was never even considered to be used, or it was treated as another dynamic library (a dynamic library version alongside the static library perhaps?). Given my level of expertise, I wouldn't be surprised if it was something else though. I have never tried what you're doing, and if I would have to, I'd trust a tool like libtool to do "the right thing", which was written for precisely this kind of jobs.
  3. Alberth

    Symbol lookup error on Linux

    I conclude from this error that the "happens at compile time" isn't actually happening. The dynamic library shouldn't have unresolved links to the static library. Note that in itself, a dynamic library with unresolved links is not bad. Maybe the program you dynamically link to has that code, or maybe you would load a second dynamic library with that missing code. This is why you don't get a linking error while building the dynamic library. EDIT: You may want to copy/paste the actual link command of the dynamic library being executed in a post here. While I can likely not say anything useful about it, but other people may understand what flag you should add.
  4. Alberth

    Symbol lookup error on Linux

    I considered that question, but ended with the conclusion that it wouldn't matter. A linker only adds code for symbols that you reference, so you must be very lucky, or you must reference the exact functions that you need eg from the game program to force the linker to include it. Even if you did, I am not sure the symbol would be exported for the dynamic library to find. Anyway, dynamic libraries are added at runtime, at which point there is no linking support for adding static libraries anymore, since "static" implies "at compile time". BTW: There is an application to decode the c++ symbols: $ c++filt _ZN15CProfileManager5ResetEv CProfileManager::Reset()
  5. Alberth

    Symbol lookup error on Linux

    Not much into how libraries work, but referencing a static library from a dynamic library sounds like a problem. A static library is added to the code at compile time, which apparently didn't happen. In other words, your dynamic library should have included the static library already, I think. Something may have gone wrong while linking your dynamic library. As for fixing, I would likely use libtool. CMake may be the least worse solution for cross-platform, but in my experience it's horribly bad both in documentation and in understanding its job.
  6. Designing good looking collections of coloured pixels (aka, an image), is not related to a platform at all. At the end of the day you have a .png or so, which can be used at any platform. As such, any software that can produce such a file can be used. Obviously, there are a zillion such software packages. Just pick one that works for you (try a few), and use that.
  7. Exactly. If you write your big adventure now, and you pick the wrong approach at the start, you're in big trouble, as by the time you realize you should have done it differently, it's one big bulk of code. If you do the small experiments, not only write them, but also put them away for a day to a week, and then look at it again when you have plenty of time to study and think about it. How does the code look to you then? (I promise you, it'll be different from when you were just finished writing the code.) Is it good code to you? As a thought experiment, suppose I have this a 100 times larger, would it still be nice? If not, why? How can it be improved to make it nicer at the big scale? Once you decided the new way to do things, repeat the entire exercise. Do this until you think you found the proper approach to your problem. Then try it "for real", and see if you were right. You can also use this approach to try a new thing, or to compare two alternative solutions. The whole point of this small scale coding is that it's not expensive to make mistakes, and you learn a lot from it. Also, coding the solution forces you to do everything, you can't forget some part, or it won't work (A high risk if you just think about it.).
  8. I'd suggest to do simple experiments, eg - Switch and a door, you have to throw the switch before you can use the door. - Somewhat more difficult 2 switches and a door, switches must be in the same position. - More common form, switch, door, key to second door behind the first door. It's not so much an adventure to play, but an adventure to program. You get through the process of writing the program, and managing all the variables. They are sinmple enough to try again if you don't like the solution in some way, while you pick up nice pieces of code and knowledge how these things work.
  9. A single level struct X foo[3] = { {...}, {...}, {...} }; A 2D array needs an additional set of brackets, ie your example compiled here using struct dynamic_pfl arr_dynamic_pfl[5][20] = { { {false, 1,4,2, 40,0,0, 420,580,0, 128,64,0}, {false, 2,4,2, 40,0,0,1200,580,0, 128,64,0}, {false, 1,4,2, 40,0,0, 111,580,0, 128,64,0}, {false, 2,4,2, 40,0,0,2222,580,0, 128,64,0}, {false, 2,4,2, 40,0,0, 666,580,0, 128,64,0} } }; I also changed the "level" to 5, since my gcc compiler complained about it: x.c: In function ‘main’: x.c:25:10: error: variable-sized object may not be initialized struct dynamic_pfl arr_dynamic_pfl[level][20] = {
  10. Include files have no relation to library files. The only thing in common between them is that the developer should describe the content of the latter in the former, that's all. What you see as "the compiler" is really at least 2 programs (and probably more, but 2 is enough for the explanation). One program is the "true compiler", and the other one is the linker. The "true compiler" reads your C++ files, and your include files, and checks if they make sense (stuff that you use must be declared somewhere in the same or another file). If it is happy, it produces one or more object files. This is the compiled C++ code. In particular, this compilation step takes the content of include files (and your c++ files) as the one and only truth, it does not check for existence of library files, nor does it do any other form of checking on your library files at all. Once all object files have been produced, everything is shipped to the linker. The object files are all partial files, they have "holes" where the linker can insert calls to other object files, and to libraries. Each hole has a name associated with it, so the linker knows what it should insert at that point. The linker doesn't care about your source code at all, it just has these object files and libraries, which all have some names of routines that they have code for, and holes with a name for calls to other objects files (and libraries). The linker places all object file after each other, and resolves each hole by finding a matching name in some other objec file. If it runs out of holes to resolve, it's happy, and you have an executable program. If it can't resolve a hole due to missing a routine with a matching name, it throws errors printing the name (in a pretty c++ notation) of routines that it misses. If you remove the Perlin line, you basically have the true compiler generate a few less holes in one of the object files. The linker becomes happy as well then, as it can resolve all other holes (there were no other missing routines in its report previously), and "it works". It's not because you fixed anything, you just eliminated the need for having the library around for the linker.
  11. Did you verify that the missing functions are defined in the header file? (they should be) Perhaps this noise thing library is messed up. Did you try another library? (using the same path as much as possible) Since linking is all you want to try, perhaps write a trivial test program to try it? Easier to change than your main game program, and if you make a mess of it, you can just delete everything without doing any harm.
  12. Just have two separate collections std::set<Sword> swords; std::set<Staff> staffs; They can have a common base class if you like. However, both being long pointy things is not enough reason imho to keep them together.
  13. Thanks for the feedback, glad it works for you. Albert
  14. Minecraft could perhaps work (never played it, not sure if it is appropriate). More serious programming could be Scratch, which is based on a "stage" where everything happens, with lots of graphics etc. Aimed at around his age, I think. Lego with some form of computers could do the job also if he's more into building than programming.
  15. So break up your nested constructors? One simple-minded way to go about it is to perform bottom-up instantiation in the main function (I am sure you can think of a smarter solution, I don't have enough details to give you much help there). int main() { w = new World(); // Maybe it has more parameters than 0, but hopefully not many. // Make an aircraft, could be done in a separate function. text = new TextNode(...); aircraft = new Aircraft(text, ...); w.add(aircraft); // Add it to the world. ... // Other world additions game_stat = new GameState(w, ...); // Not sure what this is, but apparently you need it. // Not sure how much Context you'd still have in this setup. application = new Application(game_state); application.letsplay_the_game(); return 0; } Instead of nesting everything into a deep structure in the constructors, build a small part of it, and add it to the collection, or use it in other parts. You have the room to have many variables with all the data that you need to have around, although you may want to organize as well at some point. Eg have a TextNodeFactory instance which knows about textures, and builds TextNode instances (and other things with textures). Have an AircraftFactory which produces Aircraft instances is also an option. Basically, you'll see patterns of the same code being copied into this main function, at which time you have to start thiking how to eliminate that code duplication (either as a separate function, or if it has much data, as a separate class).
  • 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!