Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by darenking

  1. Thank you all. You're magic.
  2. Hi, Just a small thing. I'm using Allegro C++. I have a vector of bitmap pointers: vector<BITMAP*> m_Sprites; I just want to be able to change one of these sprites, let's say the third sprite, in a method. So I need to pass it, not by copy of course but by reference or whatever. I know I will be using something like this: m_Sprites[2]. But I don't know about the pointers and/or references. I sorta get the idea of them but can never do the syntax!
  3. Howdy gang. I need to nest a class inside another class. I've seen some examples of it on the interweb but none which address my two main problems. The first is that my code is in separate files (.h and .cpp), whereas most examples don't address this. Second issue, my two classes are huge (my World object and a Loader object that sits along side it but I want to put inside it), so I would prefer to keep the code in two separate files. Any takers? [Edited by - darenking on August 31, 2005 7:36:56 AM]
  4. One advantage is one fewer .h files. I've got all this working now so thanks all!!!
  5. So there is no way of doing it whereby it would be able to access them with m_Parent.m_Sprites rather than m_Parent->m_Sprites ?
  6. OK gang, I now have my World object with a nested class called WorldLoader. In the update method of World, I check to see if new data needs to be loaded (started a new level) and if so, create a new instance of WorldLoader and access its Load method: //in world.cpp... (simplified, I check for load failure and stuff) if ( ! m_Valid ) { m_Valid = true; WorldLoader worldLoader; worldLoader.Load(); } Question is, how does WorldLoader access the data members of World? It needs to load bitmaps into its vectors, for example. Here are some of the variables, objects and Allegro bitmaps that will need to be modified. They are all private, would rather not make them public as I don't want the object that creates World to be able to access them. These are part of World. WorldLoader is a private member of World too. private: int AmountOfHairyScaryMonsters; Maze m_Maze; vector<Actor*> m_Actors; vector<BITMAP*> m_Sprites; Camera m_Camera[9]; vector< vector<int> > m_Cycles; class WorldLoader { public: WorldLoader(); ~WorldLoader(); void Load(); }
  7. I've got it working anyway. You're my hero. Have rated you up to the max.
  8. I'm confused now. I said don't we need an include for bar.h and you said we do and you've put one in, but there isn't one there and anyway there isn't a bar.h so why did I say it? I think I shall have a lie down.
  9. Excellent but don't we need an include for bar.h in bar.cpp? (error in the example?)
  10. No but I've seen the Athlon Buddists in southern China. Boy do those women go!
  11. Although I'm using Allegro, I don't think this is really an Allegro question as what I need to know is the principle of how pixels are blended. I'm writing my own alpha blending function, as I need it to be more flexible than the standard Allegro functions. I can use getr32(), getg32(), getb32() and geta32() to get the red, green, blue and alpha values of a pixel in the source and destination bitmaps. I can then use colour = makeacol(red, green, blue, alpha) to make the new colour with an alpha value. Finally I can putpixel(destination, x, y, colour) to put the pixel. But how do I decide on the levels of each colour and the alpha level? Let's say the source pixel is red with 50% translucency... 255, 0, 0, 127 And let's say we want to place it on a pixel that is grey with a translucency value of 150 (out of 255, which I guess is about three-fifths solid)... 100, 100, 100, 150 What would the final values be? Do I just add the colours together for example? Or do I deduct colours? If I deduct colours, which from which? The lowest from the heighest? Do I have to use the alpha value to alter the colour of each channel? I should mention that what I am creating is another alpha sprite. I'm not drawing a sprite to a solid background. I'm creating a new alpha sprite from two other alpha sprites, and the new alpha sprite must be capable of being placed finally on a background. For example, I may be drawing a brown hair shape, like a wig, on top of a pink head shape. This means of course that both sprites, the hair and the wig, will have zero pixels around the outside of the image (transparant), 255 in the middle for the solid areas, and pixels in the range 1-254 along the rim, if you see what I mean, to create the anit-aliasing style effect. So I can't just dump one on top of the other using draw_sprite_alpha(). Any help appreciated! [Edited by - darenking on August 30, 2005 7:54:27 AM]
  12. Much faster than a human could do it by hand, with coloured beads and pieces of cloth for example.
  13. Personally I'm only using these routines to create my character sprites at the start of each level, so even if it is horribly slow, I expect we're still talking about less than a second even if there were hundreds of sprites?
  14. Yes, that is well and truly cleared up. It's just the same as declaring anything else, such as a string or an int. I'm such a dullard. Off to snog a mallard.
  15. I'm creating an object then deleting it after accessing one of its methods. I'm doing it like this: Creator* creator = new Creator(); if ( creator->File() ) { delete creator; } It looks daft to me, as it looks like I'm creating a pointer to an object then dereferencing it. Why can't I just create an object instead of a pointer to an object, I thought. So I tried it like this: Creator creator = new Creator(); if ( creator.File() ) { delete creator; } ...but I get an error, "converstion from 'Creator*' to non-scaler type 'Creator' requested". What can it all mean? Was just hoping to simplify things a little. [Edited by - darenking on August 30, 2005 8:18:35 AM]
  16. Anyway thanks very much for that mike, you totally saved my life. Have rated you up.
  17. Thanks for this Mike. There's a couple typos I picked out, inrColor should be intColor, and I assume realColor nc should be intColor nc? Both in this function: inrColor realColorToIntColor(realColor c) { realColor nc; // should this be intColor? nc.r = c.r*255; // cast??? nc.g = c.g*255; nc.b = c.b*255; nc.a = c.a*255; return nc; } If I make those changes I get a warning "converting to 'int' from 'float'". Shall I do a cast or something? Or does it signify a problem with the code?
  18. Thanks for that mike. So, how do I find that mysterious final alpha value? Also I still don't get how I can put these examples into my program, as you use the colour and the alpha, whereas I have a value that is made up of the three colours and the alpha, and four values 0-255 representing the three colours and the alpha all separate. Any ideas? Anyone fancy chalking up an example? Remember I want to finish with a new alpha sprite rather than a flat image, I'm not drawing to a background here. I'm blending two alpha sprites together to form a new alpha sprite, that I can finally draw onto the screen buffer. This is what I have value-wise: pixFrom, pixTo // two ints consisting of RGBA which can be separated into... redFrom = getr32(pixFrom); greenFrom = getg32(pixFrom); blueFrom = getb32(pixFrom); alphaFrom = geta32(pixFrom); redTo = getr32(pixTo); greenTo = getg32(pixTo); blueTo = getb32(pixTo); alphaTo = geta32(pixTo); [Edited by - darenking on August 28, 2005 5:22:51 AM]
  19. Quote: Cc = Ca*Aa/255 + Cb*(255-Aa)/255 Cc = (Ca*Aa+128)/255 + (Cb*(255-Aa)+128)/255 Cc = (Ca*Aa + Cb*(255-Aa) + 128)/255 Also I'm confused as to why Ab isn't mentioned in these formulas. Or does Cb contain Ab? Remember I want to blend both images together to create a new sprite rather than just draw sprite a onto a flat bitmap b, creating an alpha sprite rather than a flat bitmap!
  20. I'm a bit confused to be honest. I start with my two pixels, the pixel at coords x and y in the from image, and the same pixel in the destination image: pixFrom pixTo Do I keep them like this or do I have to extract the three colours and the alpha from each, eg: redFrom = getr32(pixFrom); greenFrom = getg32(pixFrom); blueFrom = getb32(pixFrom); alphaFrom = geta32(pixFrom); redTo = getr32(pixTo); greenTo = getg32(pixTo); blueTo = getb32(pixTo); alphaTo = geta32(pixTo); Or, judging by your examples, I need the alpha colour and a mixture of the three colours?
  21. I have a class called World that stores all data for my game, and I'm creating a class called Creator that loads bitmaps and other data into World's vectors. Originally, the instance of Creator was a member of World, and World passed pointers to its vectors to Creator. Creator stored these pointers and dereferenced them when it needed to add bitmaps or whatever to the vectors. But I realised I was passing a huge number of pointers. So, I have decided to make Creator a friend of World so that it can see World's vectors directly. I have had a few problems with this. Firstly, I wasn't sure if Creator should be a member of World, or should sit alongside World? Currently I have both Creator and World as members of another object, my game engine called Engine. // in Engine.h World m_World; Creator m_Creator; (I have also tried creating the Creator instance with 'new', but the problem is still the same.) It all compiles and runs fine, except, bizarrely, although there should be just one instance of World, there is now two instances. One is created and then destroyed. Then the other is created, destroyed at the end of the program. (I know this because the constructor and destructor for the World object log messages to a log.txt file.) The first instance of World is created when the program first runs, then destroyed after the first call to Creator: m_Creator.File(m_World); After this call, m_World is destroyed along with all of the bitmaps that Creator put into its vectors. m_World is then created again the next time one of its methods is called: m_World.Update(); Naturally it is then destroyed at the end of the program. Hmm... What could be causing the destruction and reconstruction of the m_World object? Maybe it could be to do with the following, which I read somewhere on the net, which follows an example of friend classes: Quote: You may also see something new in the first instruction of the program, that is the empty prototype of class CSquare. This is necessary because within the declaration of CRectangle we refer to CSquare (as a parameter in convert()). The definition of CSquare is included later, so if we did not include a previous definition for CSquare this class would not be visible from within the definition of CRectangle. The example that it gives, with square and rectangle objects, has everything in one file. Of course my program has each class in its own .h and .cpp files. If I need an empty prototype of one of the classes (World?) where should I put it? Or is it some other problem? [Edited by - darenking on August 20, 2005 11:45:09 AM]
  22. darenking

    C++ friend classes dilemma

    Quote: How does Creator know what to fill World with? - it reads in the text file and follows commands. I've written all that and it works. Quote: When does Creator do this? - When it's told to. Engine knows when it's time to start a new level and will tell World the level number and to update. I think it is best if Creator is a nested class inside World, private so that Engine doesn't know about it. Engine will tell World to update itself, and won't know or care how it does that. When World is told to update, it will create an instance of its private nested Creator object, call its main function, then destroy it. That all sounds simple enough. Every object only knows what it needs to know and does what it needs to do. The stuff that reads in the text file and executes its commands is all contained in Creator and therefore can be destroyed once it has done its job, ie before the gameplay begins for the current level. So that is what I want to do, make Engine a nested class of World. I get the concept but will probably have a hard time implementing it as it sounds like it could be tricky syntax. I didn't understand your examples above, with stuff like: Creator( World& world ) : world_( world ) {}; But perhaps I don't need that; wasn't that when Creator was going to be created in World's constructor? Creator is going to be created in a member function of World called update(), then destroyed after it has done its work, something like this, I hope: Creator* creator = new Creator(); if ( creator->File(&this, level) ) //pass address of world, or maybe we don't need to? delete creator; else return;
  23. darenking

    C++ friend classes dilemma

    Quote:In fact, if I understand correctly, Creator's function should be completely transparent to World, so World doesn't even need to know there is a Creator class. Hmm, but how can World not know that there is a Creator class if Creator is inside World? And surely it would be World that calls Creator when it needs to be filled up with data and stuff?
  24. darenking

    C++ friend classes dilemma

    Quote:Original post by stylin Assuming creator is called once in the beginning of the program, then is immediately deleted after it sets world up, then you should make it a private member of world, and construct it in world's contructor initializer list. Actually Creator's job is to create the current game level, so it needs to fill World with goodies at the start of each level. Part of why the way World is filled is so complicated is that my monster sprites and whatever are constructed out of masks and textures so that they can be different each time, randomizing the colours for example, or choosing randomly from dozens of head shapes. So World definitely needs to call Creator in one of its methods - probably in World::Update(), after checking to see if you've just started a new level. With this in mind, does Creator still need to be a nested class? (And do nested classes need to be friends? I guess not.) I'd much rather avoid nested classes, if I can, but need to deal with that circularity problem. * Maybe I can use the extern keyword in World to tell it about Creator? *
  25. darenking

    C++ friend classes dilemma

    I'm trying to just have the instance of Creator as a member of World, in the same way that World is a member of Engine, ie not as a nested class... as I don't really understand why it should be nested, when World isn't nested inside Engine. There's a circularity problem though: world.h needs #include "creator.h", and creator.h needs #include "world.h", which of course doesn't compile. Is this something to do with why it would need to be a nested class? I mean, world.h is a member of engine.h, but that's not a problem because world.h doesn't need to modify engine.h or even know of its existence.
  • 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!