Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (540)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  [Don't even look] I think I've found a bug in my brain  (Read 3640 times)
0 Members and 1 Guest are viewing this topic.
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Posted 2011-11-02 03:25:28 »

I think I've found a bug.

I got this result, from some code:


Obviously, I'm drawing green rectangles, underneath the pictures.

Now, if I comment it out (and that is the ONLY change made to the code):

and

Depending on where the X-coord for the camera is set.
..also, this doesn't move smoothly, like normally, but in 10 pixel steps.

Boils down to just odd behavoir, because this shouldn't work that way.

Code, for people interrested:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
// World-rendering
      int startingX = cameraX / 10;
      g.setColor(Color.green);
      for (int x = startingX; x < 50 + startingX; x++) {
         for (int y = 0; y < 20; y++) {
            if (level.getBrick(x, y) != null) {
               int k = x * 10;
               int startDrawX = k - cameraX;
               int startDrawY = 200 - ((y + 1) * 10);
               g.drawRect(startDrawX, startDrawY, 10, 10);
               
               Brick brick = level.getBrick(x, y);
               BRICK_TYPE type = brick.getType();
               ResourceManager.TILE image = type.getImage();
               g.drawImage(graphics.getSprite(image.getX(), image.getY()), startDrawX, startDrawY);
            }
         }
      }


EDIT:
Can anyone explain this behavoir, or suggest a way to fix it? I got no ideas as to why this is happening. I just cleaned up my code, so it shouldn't be spaggetthi-loops and oddness.

Offline jonjava
« Reply #1 - Posted 2011-11-02 06:34:27 »

Your code, to me, is a bit confusing.

I'd suggest that you'd implement the drawing of the Brick inside the Brick class instead. You could, for example, make 2 methods. One to draw a green rectangle at the Bricks position and another to draw the sprite.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
class Brick {
int xPosition = 0;
int yPosition = 0;
int width = 10;
int height = 10;
Image image = null;

// Constructor
public Brick(int x, int y) {
     this.xPosition = x;
     this.yPosition = y;
     this.image = ResourceManager.getImage();
}

// Paint methods
public void drawRect(Graphics g, int x_offset, int y_offset) {
     // the offset values are used to shift the bricks to any position relative to the screen.
     g.setColor(Color.green);
     g.drawRect(xPosition + x_offset, yPosition + y_offset, width, height);
}

public void drawImage(Graphics g, int x_offset, int y_offset) {
      if (image = null) return; // If we have no image, don't draw anything
     g.drawImage(image, xPosition + x_offset, yPosition + yOffset);
}
}


And then to draw the bricks, just loop through them all and decide if they are within the view and if they are, call their paint methods:

1  
2  
3  
4  
5  
6  
7  
8  
// World-rendering
Iterator itr = (level.listOfBricks).iterator();
// Assuming you've saved all Brick objects in an ArrayList called listOfBricks in the level object.
while (itr.hasNext()) {
      Brick b = itr.next();
     b.drawRect(g, 0, 0);
     b.drawImage(g, 0, 0);
}


Also, if you hold down ALT while you take a screenshot with PrintScreen, you will only take a screen shot of the active window ( so you don't have to crop out the whole desktop in paint:) )

Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #2 - Posted 2011-11-02 08:46:55 »

@JonJava
Uh, and how would that fix the seams he's experiencing?

Don't assume that a problem is a bug in someone else's released code. Only accuse others when you've tried everything.
You're also not posting much of the relevant code either. I mean, you have a draw problem, so why not post the code concerning drawing? Also more code comparisons between when it works and when it doesn't. You're probably either removing some vital part for all rendering when you comment out the green box drawing (you're forgetting to set something) or you have leftover code in your green box drawing that corrupts some setting. Either way, it's impossible to tell for me with only this code to go by.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 437
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2011-11-02 09:12:48 »

The bug is not in LWJGL. It's unlikely that it is in Slick too but not impossible.

Cas Smiley

Offline Cero
« Reply #4 - Posted 2011-11-02 11:47:28 »

Cannot comment on that code, since, yeah its confusing

First of all it is always most likely that the code you write is buggy instead of the libraries you use.

But I gotta say Slick has a couple of bugs which nobody seems to know/fix/care for - whatever
bugs with colors
textures that aren't destroyed / loaded / rendered under certain circumstances; related: textures stay whit, black or show a different texture in shrinked form
and especially the blending modes are screwed up / or draw modes as they are called

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #5 - Posted 2011-11-02 16:04:47 »

I did not mean to promote my code, over Slick, or saying that mine is better. I have a lot of respect for kevglass' code. However, I am stating that the only thing changing in MY code, is that one call to g.drawRect, which seems to change a lot. More than just a rect. Now, this seems to me, like something is wrong.

I'm having my drawing logic in the screen, and not in the brick, because my Brick is only a data object. I find it more correct, to have it in screen.
Screen is drawing brick - not brick.

The code I posted is very relevant:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
// World-rendering
        int startingX = cameraX / 10;
        g.setColor(Color.green);
        for (int x = startingX; x < 50 + startingX; x++) {
            for (int y = 0; y < 20; y++) {
                if (level.getBrick(x, y) != null) {
                    int k = x * 10;
                    int startDrawX = k - cameraX;
                    int startDrawY = 200 - ((y + 1) * 10);
                    g.drawRect(startDrawX, startDrawY, 10, 10);
                     
                    Brick brick = level.getBrick(x, y);
                    BRICK_TYPE type = brick.getType();
                    ResourceManager.TILE image = type.getImage();
                    g.drawImage(graphics.getSprite(image.getX(), image.getY()), startDrawX, startDrawY);
                }
            }
        }

Applies to the first picture.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
// World-rendering
        int startingX = cameraX / 10;
        g.setColor(Color.green);
        for (int x = startingX; x < 50 + startingX; x++) {
            for (int y = 0; y < 20; y++) {
                if (level.getBrick(x, y) != null) {
                    int k = x * 10;
                    int startDrawX = k - cameraX;
                    int startDrawY = 200 - ((y + 1) * 10);
                    //g.drawRect(startDrawX, startDrawY, 10, 10);
                     
                    Brick brick = level.getBrick(x, y);
                    BRICK_TYPE type = brick.getType();
                    ResourceManager.TILE image = type.getImage();
                    g.drawImage(graphics.getSprite(image.getX(), image.getY()), startDrawX, startDrawY);
                }
            }
        }


Applies to the second, and third.

Also, I believe I've tried everything with this. I mean; there isn't much to try. The comment should remove the green rects. Obviously, it's not doing that.

EDIT: It seems to boil down to, wether I draw the rects first, or the images first. If the rect if not drawn before the images, it f's up.
Can anyone suggest a better way to debug this? Things I could try?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
if (level.getBrick(x, y) != null) {
               Brick brick = level.getBrick(x, y);
               BRICK_TYPE type = brick.getType();
               ResourceManager.TILE image = type.getImage();
               
               int k = x * 10;
               int startDrawX = k - cameraX;
               int startDrawY = 200 - ((y + 1) * 10);
               Image drawImage = graphics.getSprite(image.getX(), image.getY());
               g.drawImage(drawImage, startDrawX, startDrawY);
               //g.drawRect(startDrawX, startDrawY, 10, 10);
            }

Same exact result.

Offline jonjava
« Reply #6 - Posted 2011-11-02 16:51:38 »

Why isn't the FPS, yVelocity etc (like the one in the first picture) shown in the 2 others screenshots?

[EDIT]
Quote
I'm having my drawing logic in the screen, and not in the brick, because my Brick is only a data object. I find it more correct, to have it in screen.
Screen is drawing brick - not brick.

It irks me greatly to hear this since I would find my method way more in line with good OOP design and much more clean, clear and organized and efficient etc. The screen does of course paint the Bricks - it just lets the Brick handle its painting. The screen doesn't care HOW the brick works or how it looks or how it paints itself - let the Brick handle that. I just felt I had to give you my opinion.Smiley

Offline loom_weaver

JGO Coder


Medals: 17



« Reply #7 - Posted 2011-11-02 17:55:22 »

After reading the original post I still don't understand what the problem is.

What is the expected behaviour and what are you seeing and how does it differ from what you expect?

This what I am assuming: you have commented out the green rectangle drawing.  Now the bricks are being drawn in the incorrect location because in the original frame the arch took up most of the screen and in the latter two frames you can only see the bottom.
Offline Cero
« Reply #8 - Posted 2011-11-02 20:19:23 »

wether I draw the rects first, or the images first

yes. I actually recall that behavior when we tried to implement or LWJGL particle system in our game which is Slick - and those blending modes just clashed.
my conclusion was that, drawing images in Slick somehow changes the blending mode also - so the order matters

try to make a simple isolated example
I haven't really bothered because it seems that Kevin is quite busy and these things are so... well hard to detect, and few people use Slick for big things... you know
which is why I will switch to pure LWJGL soon, only using Slicks Audio implementation

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #9 - Posted 2011-11-02 21:11:00 »

After reading the original post I still don't understand what the problem is.

What is the expected behaviour and what are you seeing and how does it differ from what you expect?

This what I am assuming: you have commented out the green rectangle drawing.  Now the bricks are being drawn in the incorrect location because in the original frame the arch took up most of the screen and in the latter two frames you can only see the bottom.

First image, is what I want. However, without the green rects.

Second image, is what happens when I comment them out.

Third image, is when moving the world over the X axis, which works just fine if i draw the rects. Without the rects, it even moves on the y-axis as well.

Why isn't the FPS, yVelocity etc (like the one in the first picture) shown in the 2 others screenshots?

[EDIT]
Quote
I'm having my drawing logic in the screen, and not in the brick, because my Brick is only a data object. I find it more correct, to have it in screen.
Screen is drawing brick - not brick.

It irks me greatly to hear this since I would find my method way more in line with good OOP design and much more clean, clear and organized and efficient etc. The screen does of course paint the Bricks - it just lets the Brick handle its painting. The screen doesn't care HOW the brick works or how it looks or how it paints itself - let the Brick handle that. I just felt I had to give you my opinion.Smiley

Good observation. To be honest, all the other code, except form the rects, are exactly the same.
No clue why they get left out.

Well, that is a design question Wink I respect your opinion though. Would you also let the bricks update themselfes? What about the player?
How is level, monster and player interference going to work, if each class handles ifself in that manner?
That's just questions I don't want to deal with. Also, I can use my creature class for all creatures in the game - including the player.

wether I draw the rects first, or the images first

yes. I actually recall that behavior when we tried to implement or LWJGL particle system in our game which is Slick - and those blending modes just clashed.
my conclusion was that, drawing images in Slick somehow changes the blending mode also - so the order matters

try to make a simple isolated example
I haven't really bothered because it seems that Kevin is quite busy and these things are so... well hard to detect, and few people use Slick for big things... you know
which is why I will switch to pure LWJGL soon, only using Slicks Audio implementation

Thanks for the post. Good to know I'm not the only one.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #10 - Posted 2011-11-02 21:32:36 »

I tried this, while altering showRects on keyPress.
1  
2  
3  
4  
5  
if (showRects) {
   g.drawRect(startDrawX, startDrawY, 10, 10);
}
Image drawImage = graphics.getSprite(image.getX(), image.getY());
g.drawImage(drawImage, startDrawX, startDrawY);


Problem persists, but only when showRects are off. I can't seem to reproduce the problem, but it can't seem to make it disappear.
Anything I could try? Any graphics trickery, or anything that could help?

Offline Cero
« Reply #11 - Posted 2011-11-02 22:23:36 »

yeah I can't find any misuses of glBlendFunc in the code

if you can create like a simple Slick class which shows this problem...

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #12 - Posted 2011-11-02 23:13:33 »

I can't reproduce the problem, but I can definitely hand over my source, and a runable jar for you to look at.
http://www.javadaemon.com/problemjar.zip contains both the source, and a runnable jar.

controls:
k - toggle wether or not to draw the rects
a and d - move camera
arrow keys and space - move around

Please look at the source, and even decompile if you don't believe me. This is very odd


EDIT:
This is the whole render loop:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
@Override
   public void render(GameContainer container, Graphics g)
         throws SlickException {
      StaticWorld level = model.getLevel();
      Creature player = model.getPlayer();
     
      final SpriteSheet graphics = ResourceManager.getRessourceManager().getGraphics(); // Get the sprite sheet
      graphics.startUse();

      // World-rendering
      int startingX = cameraX / 10;
      g.setColor(Color.green);
      for (int x = startingX; x < 50 + startingX; x++) {
         for (int y = 0; y < 20; y++) {
            if (level.getBrick(x, y) != null) {
               Brick brick = level.getBrick(x, y);
               BRICK_TYPE type = brick.getType();
               ResourceManager.TILE image = type.getImage();
               
               int k = x * 10;
               int startDrawX = k - cameraX;
               int startDrawY = 200 - ((y + 1) * 10);
               if (showRects) {
                  g.drawRect(startDrawX, startDrawY, 10, 10);
               }
               Image drawImage = graphics.getSprite(image.getX(), image.getY());
               //g.drawImage(drawImage, startDrawX, startDrawY);
               drawImage.draw(startDrawX, startDrawY);
            }
         }
      }

      // Player rendering
      g.setColor(Color.orange);
      int screenX = (int) player.getWorldX() - cameraX;
      int screenY = 200 - (int) (player.getWorldY());
      g.drawRect(screenX, screenY, player.getWidth(), player.getHeight());
     
      g.drawString("yVelocity: " + player.getYVelocity(), 10, 20);
      g.drawString(player.getWorldX() + " " + player.getWorldY(), 10, 30);
      g.drawString(player.isJumping()+"", 10, 40);
     
      graphics.endUse();
   }

Offline kevglass

« JGO Spiffy Duke »


Medals: 219
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #13 - Posted 2011-11-02 23:23:52 »

Calling g.setColor() or g.drawRect() or g.drawImage() is always going to go wrong up inside a startUse()/endUse(). Start/End uses one set of geometry to speed things up, it's described on the wiki and in the javadoc.

In your case you don't need to startUse() or endUse(). If you want to use them you need to use Image.drawEmbedded()

Cheers

Kev

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #14 - Posted 2011-11-02 23:26:32 »

Calling g.setColor() or g.drawRect() or g.drawImage() is always going to go wrong up inside a startUse()/endUse(). Start/End uses one set of geometry to speed things up, it's described on the wiki and in the javadoc.

In your case you don't need to startUse() or endUse(). If you want to use them you need to use Image.drawEmbedded()

Cheers

Kev

YES! Thank you so much! Ofcourse it was something like that Cheesy Appriciation++;

Offline cylab

JGO Ninja


Medals: 55



« Reply #15 - Posted 2011-11-03 08:47:19 »

It irks me greatly to hear this since I would find my method way more in line with good OOP design and much more clean, clear and organized and efficient etc. The screen does of course paint the Bricks - it just lets the Brick handle its painting. The screen doesn't care HOW the brick works or how it looks or how it paints itself - let the Brick handle that.
It irks me greatly to hear this, since I think throwing in an argument of "good OOP design" just because it would look more familar to you is just complete BS. And to say, that it is more organized and efficient id plainly wrong. Actually all abstractly designed graph/scene/3D engines use a clear separation of data and drawing code. Either to enable them to visualize the same data in different ways or to switch the backend renderers to take advantage of new hardware features or different drawing APIs.

I just felt I had to give you my opinion.Smiley
I just had to say you, that your opinion is exactly that - an opinion - nothing more  Tongue

Mathias - I Know What [you] Did Last Summer!
Offline princec

« JGO Spiffy Duke »


Medals: 437
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2011-11-03 11:52:38 »

All of OOP is opinion and wankery Smiley There are many ways to kill a cat other than skinning it.

Cas Smiley

Offline Fokusas

Senior Devvie


Medals: 3
Projects: 1



« Reply #17 - Posted 2011-11-03 12:12:43 »

This topic name change looks EPIC  Grin Grin Grin Grin and makes me laugh.
I think that all people have some bugs in they brains, but only programmers can understand that  Grin (or other clever people). And it is common for people to make mistakes. If we don't do them we will be computers Cheesy
P.S. sorry for offtopic  Grin
Offline kevglass

« JGO Spiffy Duke »


Medals: 219
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #18 - Posted 2011-11-03 12:14:24 »

The scary thing about that is that you think programmers are "clever" Smiley

Kev

Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #19 - Posted 2011-11-03 12:25:09 »

The scary thing about that is that you think programmers are "clever" Smiley

Kev
Yeah, literally implying that you have to be clever to be a Programmer with a big P at a big company.

Myomyomyo.
Offline Fokusas

Senior Devvie


Medals: 3
Projects: 1



« Reply #20 - Posted 2011-11-03 12:28:34 »

Yes its scary because only "clever" peoples can start searching for bugs in them and scarer then they found them. And that isn't hygiene issue.  Grin
P.S. I can't stop laughing reading this topic especial last posts Cheesy
Offline ReBirth
« Reply #21 - Posted 2011-11-03 14:53:49 »

So there is difference between "programmer" and "Programmer"... I just know...

Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #22 - Posted 2011-11-03 18:57:09 »

TheDailyWTF.com, dedicated to Programmers. I am in no way claiming to be a pro coder here. I just think it's funny how incompetent some people are when it comes to computer stuff. I've gotta admit that I've learned a lot just from that site. xD Ahahaha...

Myomyomyo.
Offline jonjava
« Reply #23 - Posted 2011-11-03 23:23:40 »

It irks me greatly to hear this since I would find my method way more in line with good OOP design and much more clean, clear and organized and efficient etc. The screen does of course paint the Bricks - it just lets the Brick handle its painting. The screen doesn't care HOW the brick works or how it looks or how it paints itself - let the Brick handle that.
It irks me greatly to hear this, since I think throwing in an argument of "good OOP design" just because it would look more familar to you is just complete BS. And to say, that it is more organized and efficient id plainly wrong. Actually all abstractly designed graph/scene/3D engines use a clear separation of data and drawing code. Either to enable them to visualize the same data in different ways or to switch the backend renderers to take advantage of new hardware features or different drawing APIs.

I just felt I had to give you my opinion.:)
I just had to say you, that your opinion is exactly that - an opinion - nothing more  :P

You're right, it is my opinion, nothing more - which is why I wanted to clarify it in my post.

Since the topic is solved I would like to slightly steer off-topic, :D,  and explain my reasoing behind my opinion.

1) It looks complicated. The Brick class makes me think of a 'struct' from C. I hate structs, personally. :P

2) It seems the bricks are stored in the level class. The code iterates through every x and y coordinate - checking if there is supposed to be a brick there by calling level.getBrick(). Then checks the type of the brick and with this type asks the ResourceManager what image is supposed to be drawn - Frankly, the procedure confuses me :(

3) How would you move a brick?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
moveBrick(x1, y1, x1, y2)
{

Brick brick = level.getBrick(x,y);
if (brick != null) {
     level.setBrick( brick.copy(), x2, y2);
     level.removeBrick( brick);
}
// Or something like that
}


 - Which confuses me even more :/. Instead of simply
1  
level.getBrick(x1,y1).move(x2,y2);

 or something along those lines.

I wasn't tyring to come off as a douche or a know-it-all - I apologize :(. I was just trying to promote good coding habits. I'm a pretty open minded guy but so far the method you preach seems confusing and convoluted to me. Makes me think of C :P.

I'd gladly hear reasons to why that method is better ( faster? cleaner? simpler? more efficient? ) other than the fact that someone might be used to coding that way and therefore prefers it. I was used to coding in C when I met Java. :)

Offline sproingie

JGO Kernel


Medals: 202



« Reply #24 - Posted 2011-11-04 01:10:20 »

If you hate structs, OOP might not be for you.  Just saying. Smiley

I'd call your second example far more OO than the first, since it's comprised solely of high-level messages to objects.  It does however require Brick (or at least what level.getBrick returns) to have a reference to its level so that .move knows how to update the level, so it does add some more complexity to Brick than the first approach.

Which method you use, if either, is up to what your needs are.  If only Level is responsible for tracking Brick locations, then something like the first approach makes sense (I'm not sure I'd copy).  If Bricks know their location and move themselves, the second API is the obvious approach.

Offline Cero
« Reply #25 - Posted 2011-11-04 01:22:03 »

If you hate structs, OOP might not be for you.  Just saying. Smiley

Gotta disagree: structs are C and C isnt an OOP language to begin with

Offline sproingie

JGO Kernel


Medals: 202



« Reply #26 - Posted 2011-11-04 01:44:26 »

Yes, not all structs are objects.  But all objects are structs, at least as syntax for fields goes.  If you don't like collecting your data into fields, then ... oh forget it, there's a point I can just say "you know what I meant"
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #27 - Posted 2011-11-04 02:56:28 »

It irks me greatly to hear this since I would find my method way more in line with good OOP design and much more clean, clear and organized and efficient etc. The screen does of course paint the Bricks - it just lets the Brick handle its painting. The screen doesn't care HOW the brick works or how it looks or how it paints itself - let the Brick handle that.
It irks me greatly to hear this, since I think throwing in an argument of "good OOP design" just because it would look more familar to you is just complete BS. And to say, that it is more organized and efficient id plainly wrong. Actually all abstractly designed graph/scene/3D engines use a clear separation of data and drawing code. Either to enable them to visualize the same data in different ways or to switch the backend renderers to take advantage of new hardware features or different drawing APIs.

I just felt I had to give you my opinion.Smiley
I just had to say you, that your opinion is exactly that - an opinion - nothing more  Tongue

You're right, it is my opinion, nothing more - which is why I wanted to clarify it in my post.

Since the topic is solved I would like to slightly steer off-topic, Cheesy,  and explain my reasoing behind my opinion.

1) It looks complicated. The Brick class makes me think of a 'struct' from C. I hate structs, personally. Tongue

2) It seems the bricks are stored in the level class. The code iterates through every x and y coordinate - checking if there is supposed to be a brick there by calling level.getBrick(). Then checks the type of the brick and with this type asks the ResourceManager what image is supposed to be drawn - Frankly, the procedure confuses me Sad

3) How would you move a brick?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
moveBrick(x1, y1, x1, y2)
{

Brick brick = level.getBrick(x,y);
if (brick != null) {
     level.setBrick( brick.copy(), x2, y2);
     level.removeBrick( brick);
}
// Or something like that
}


 - Which confuses me even more :/. Instead of simply
1  
level.getBrick(x1,y1).move(x2,y2);

 or something along those lines.

I wasn't tyring to come off as a douche or a know-it-all - I apologize Sad. I was just trying to promote good coding habits. I'm a pretty open minded guy but so far the method you preach seems confusing and convoluted to me. Makes me think of C Tongue.

I'd gladly hear reasons to why that method is better ( faster? cleaner? simpler? more efficient? ) other than the fact that someone might be used to coding that way and therefore prefers it. I was used to coding in C when I met Java. Smiley

One brick, is a small part of a static landscape. You do not move it. You may destroy it, and you may add to it, but you don't move it.
If you want to move it, it's not a brick.

Offline jonjava
« Reply #28 - Posted 2011-11-04 11:29:29 »

Yes, not all structs are objects.  But all objects are structs, at least as syntax for fields goes.  If you don't like collecting your data into fields, then ... oh forget it, there's a point I can just say "you know what I meant"

That's not what I dislike about Structs. Structs are fine in that sense. Structs are just a paint to work with. It's like an extremely weak version of an object.

Quote
One brick, is a small part of a static landscape. You do not move it. You may destroy it, and you may add to it, but you don't move it.
If you want to move it, it's not a brick.

Smiley

The move() method was just an example. What I'm trying to convey here is that it's best to have methods that are supposed to alter a state of a specific object is best be defined within that object. . .

And secondly, deciding that the brick is never going to move feels like limiting your options to me - unnecessarily so.

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #29 - Posted 2011-11-06 06:01:50 »

Yes, not all structs are objects.  But all objects are structs, at least as syntax for fields goes.  If you don't like collecting your data into fields, then ... oh forget it, there's a point I can just say "you know what I meant"

That's not what I dislike about Structs. Structs are fine in that sense. Structs are just a paint to work with. It's like an extremely weak version of an object.

Quote
One brick, is a small part of a static landscape. You do not move it. You may destroy it, and you may add to it, but you don't move it.
If you want to move it, it's not a brick.

Smiley

The move() method was just an example. What I'm trying to convey here is that it's best to have methods that are supposed to alter a state of a specific object is best be defined within that object. . .

And secondly, deciding that the brick is never going to move feels like limiting your options to me - unnecessarily so.

It is a data structure, and bricks are designed to sit in a grid, forming a landscape. They can only move inside this grid. Think of Minecraft.

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (24 views)
2014-12-23 03:34:11

rwatson462 (53 views)
2014-12-15 09:26:44

Mr.CodeIt (45 views)
2014-12-14 19:50:38

BurntPizza (85 views)
2014-12-09 22:41:13

BurntPizza (110 views)
2014-12-08 04:46:31

JscottyBieshaar (79 views)
2014-12-05 12:39:02

SHC (89 views)
2014-12-03 16:27:13

CopyableCougar4 (96 views)
2014-11-29 21:32:03

toopeicgaming1999 (155 views)
2014-11-26 15:22:04

toopeicgaming1999 (152 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!