Virtual Screen for starters...

Virtual Screen for starters...

Hans Spirit

Member #8,650

May 2007

Hi,

I need some help with virtual screen. I started using allegro for a month now and hadn't had any problems with it until I tried to use virtual screen.
in:
set_gfx_mode(GFX_AUTODETECT, MAX_X, MAX_Y, V_MAX_X, V_MAX_Y)

I tried to use MAX_X = 800
MAX_Y = 600
V_MAX_X = 960
V_MAX_Y = 960

Then I just couldn't start my program >:( , it crashes because the gfx_mode can't be started. My objective was to use a screen divided into 48x48 tiles, but 800x600 does not fit it and is also small for my purpose. Is there a way to use virtual screen like this ?, or is there another way do to it ?

Thanks anyway
And excuse me for any mistakes in the message, for my poor brazilian english still needs to be trained a lot more.

My Project:
Shining Legends:
http://members.allegro.cc/HansSpirit

Thomas Fjellstrom

Member #476

June 2000

Yeah, the Virtual screen is a hold over from the DOS days. Its basically only supported in DOS and possibly linux console, where it creates a "Screen" thats larger than the mode, and allows you to scroll.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elverion

Member #6,239

September 2005

The virtual screen, as Thomas Fjellstrom said, really isn't used anymore. There really is no need for it anymore. You can just keep track of world coordinates for your game objects, then draw everything by translating by those coordinates. I make use of a 2d camera class for this, since it makes things a bit easier. If you would like, I can give you the source for the camera class I've made.

--
SolarStrike Software - MicroMacro home - Automation software.

Hans Spirit

Member #8,650

May 2007

If you please .
Are you guys seeing my Avatar? Just to know if it's working, 'cause i had some trouble making it work.

My Project:
Shining Legends:
http://members.allegro.cc/HansSpirit

HardTranceFan

Member #7,317

June 2006

We can see your avatar, if it's a single image (i.e. not an animated gif)

--
"Shame your mind don't shine like your possessions do" - Faithless (I want more part 1)

Elverion

Member #6,239

September 2005

camera.h

1#ifndef CAMERA_H
2#define CAMERA_H
3 
#include <cw/cw.h> // ignore this -> self-made library
#include <allegro.h>

7 
/* How "Smooth" to make the transitions between update calls
   Higher smoothness means it takes longer to actually focus
   upon the given point */
#define SMOOTH_AMOUNT         20
12 
class CCamera;
typedef CCamera Camera;

class CCamera
{
  private:
    cw::Rect view;
  
  public:
    CCamera();
    void CCamera::set(float, float);
    void update(float, float);
    void set_view(const cw::Rect &);
    cw::Rect get_view();
    float camx, camy;
};
29 
30#endif

camera.cpp

1#include "camera.h"
2 
3CCamera::CCamera()
4{
5  camx = 0;
6  camy = 0;
7  view.x = 0;
8  view.y = 0;
9  view.w = SCREEN_W;
10  view.h = SCREEN_H;
11}
12 
13void CCamera::set_view(const cw::Rect &_v)
14{
15  view = (cw::Rect &)_v;
16}
17 
18cw::Rect CCamera::get_view()
19{
20  return view;
21}
22 
23void CCamera::set(float x, float y)
24{
25  if( x + SCREEN_W > view.x + view.w )
26    x = view.x + view.w - SCREEN_W;
27  if( x < view.x )
28    x = view.x;
29 
30  if( y + SCREEN_H > view.y + view.h )
31    y = view.y + view.h - SCREEN_H;
32  if( y < view.y )
33    y = view.y;
34 
35  camx += (x - camx);
36  camy += (y - camy);
37}
38 
39void CCamera::update(float x, float y)
40{
41  if( x + SCREEN_W > view.x + view.w )
42    x = view.x + view.w - SCREEN_W;
43  if( x < view.x )
44    x = view.x;
45    
46  if( y + SCREEN_H > view.y + view.h )
47    y = view.y + view.h - SCREEN_H;
48  if( y < view.y )
49    y = view.y;
50  
51  camx += (x - camx) / SMOOTH_AMOUNT;
52  camy += (y - camy) / SMOOTH_AMOUNT;
53}

In case you are wondering about the rects, they are just simple classes with double x,y,w, and h.
rect.h

  class cwRect;
  typedef cwRect Rect;

  class cwRect
  {
    public:
      double x,y, w, h;
      cwRect(double, double, double, double);
      cwRect(double, double);
      cwRect();
    
      bool operator = (cwRect &r2)
      {
        x = r2.x;
        y = r2.y;
        w = r2.w;
        h = r2.h;
      }
      
      Rect collision(const Rect &);
  };

So basically, the "view" of the camera is just a rectangle that encompasses the map. Generally, you go from (0,0) to (map_width, map_height) where map's width and height are in pixels. So far it's sounding pretty complicated I assume, but just check the example and you'll better understand.

Example:

1int main()
2{
/* all your initialization stuff here */
4 
/* Now we create the camera. the map width and height here
   is in tiles, so we must multiply by the tilesize for
   the camera's view.
   Then, we "set" the camera (move it to a position). */
Camera cam;
cam.set_view( Rect(0, 0, map.get_width()*map.get_tilesize(),
  map.get_height()*map.get_tilesize()) );
cam.set(player.get_x() - SCREEN_W/2, player.get_y() - SCREEN_H/2 - 100);
13 
/* other junk here */
15 
while( running )  // main loop here
{
  while( logic )
  { // do your logic here...
20 
    /* Now we use the "update" as opposed to set...
       update just means to use smooth transitioning */
    cam.update(player.get_x() - SCREEN_W/2,
    player.get_y() - SCREEN_H/2 - 100);
  }
26 
  // draw time.
  /* we need to pass the cam to the player.
     It will use the cam to correctly position it's
     sprites on the screen. */
  player.draw(&cam);
}
33 
return 0;
35}
36 
Player::draw(Camera *)
{
  /* To draw the player's sprite correctly onto the screen,
     we just need to subtract the player's coordinates by
     the camera's coordinates. */
  draw_sprite(screen, my_sprite, x - cam->camx, y - cam->camy);
}

There are some things to note. Do not actually try to compile the example. It won't run as-is due to missing code segments (obviously). You do not need to check and make sure your camera is within view. It does that automatically when using update or set.

--
SolarStrike Software - MicroMacro home - Automation software.

Matt Weir

Member #7,476

July 2006

To take it even further I would make the camera a game object like a player, enemy, magic donut etc.

This way it's trivial to create multiply cameras, cameras that move realistically, cameras with AI etc. The camera can have physics like a game object so as the player moves away from the center the camera will accelerate to catch up, a simple effect that makes things much more interesting.

Hans Spirit

Member #8,650

May 2007

Wow thanks a lot. I'm sure this will help. Now i just got to study it, and make one of my own to understand the idea. Thanks a lot for the help again.

My Project:
Shining Legends:
http://members.allegro.cc/HansSpirit

clovekx

Member #3,479

April 2003

It's not a good OO practice to have a public variables in a class. Rather make them private and use get_variablename() method. Sure this takes more time to write, but it is cleaner and easier to maintain.

---
[url http://distortum.mysteria.cz]

ImLeftFooted

Member #3,935

October 2003

Quote:

Sure this takes more time to write, but it is cleaner and easier to maintain.

I'd say its uglier and harder to maintain. The benifit as I see it is scalability. Later on you may want to set an allowable range for an attribute or something.

How is my posting?

Tobias Dammers

Member #2,604

August 2002

Quote:

It's not a good OO practice to have a public variables in a class.

It depends.
Variables that may be set to any value at any time without causing any problems to the inner workings of the class can be public, there is no harm in that. I admit, though, that this is very rare.
But then, the following is just as pointless:

class cFoo {
  private:
    int a;
  public:
    int get_a() const { return a; }
    void set_a(int _a) { a = _a; }
};

Even Java allows public member variables. Plus over-OO-ing things isn't good either. There was this story on worsethanfailure.com where they had a pacman clone that used a few thousand threads and required a 3 GHz CPU to be playable; all that due to a strict OO design.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Michael Jensen

Member #2,870

October 2002

Actually, it wasn't the OOP that slowed the game design down, it was the fact that every sprite object allocated, and used it's own thread to keep track of animation, etc -- even the dots...

I agree though, unless you have special needs on a variable (ex: it has a range, or you can't just let the programmer modify it anytime he pleases) make it public. Private should only be for things that you want to protect, or execute logic on when they change, etc...

Thomas Fjellstrom

Member #476

June 2000

You don't know if you won't need to provide special cases on variables/properties. Thats why its best to start with the access routines. so the API/ABI stays 100% consistent throughout the process. imo.

Tobias Dammers

Member #2,604

August 2002

Quote:

Actually, it wasn't the OOP that slowed the game design down, it was the fact that every sprite object allocated, and used it's own thread to keep track of animation, etc -- even the dots...

Which, one could argue, is a case of encapsulation-to-the-max. Each objects runs in its own "world".

Quote:

Generally, yes. But for some kinds of classes (I like to call them "data classes"), some parameters can be set freely to anything by design. Examples are implementations of 3d vectors, fractional numbers, ... - using getters / setters on these makes things more clumsy without adding anything. Observe:

class vec3d {
 public:
  float x;
  float y;
  float z;

  vec3d(float _x, float _y, float _z): x(_x), y(_y), z(_z) {}
  vec3d(const vec3d& rhs): x(rhs.x), y(rhs.y), z(rhs.z) {}
  // ...snip...
};

vs.:

1class vec3d {
private:
float x;
float y;
float z;
public:
vec3d(float _x, float _y, float _z): x(_x), y(_y), z(_z) {}
vec3d(const vec3d& rhs): x(rhs.get_x()), y(rhs.get_y()), z(rhs.get_z()) {}
float get_x() const { return x; }
float get_y() const { return y; }
float get_z() const { return z; }
void set_x(float f) { x = f; }
void set_y(float f) { y = f; }
void set_z(float f) { z = f; }
// ...snip...
16};

And there is not a single value you wouldn't possibly want in a vector.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Thomas Fjellstrom

Member #476

June 2000

That's quite thread unfriendly.

Tobias Dammers

Member #2,604

August 2002

Haven't done any proper multi-threaded stuff yet, so I wouldn't really know. What exactly is the problem here?

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Kitty Cat

Member #2,815

October 2002

Quote:

And there is not a single value you wouldn't possibly want in a vector.

What about NaN or Inf? Or where vec3d.magnitude() > FLT_MAX?

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Tobias Dammers

Member #2,604

August 2002

You wouldn't want these in a float either. Something like a vec3d::contains_nan() method would be useful though.
vec3d().magnitude() > FLT_MAX is a problem, but I don't see how I'd catch that in the getters / setters in a trivial way.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Thomas Fjellstrom

Member #476

June 2000

Quote:

What exactly is the problem here?

Threads accessing and changing the var at the same time can cause problems. If say you're checking for something, between the check and the execution of the code, the var could be changed and no longer actually be within the range that was checked for.

Kitty Cat

Member #2,815

October 2002

Quote:

Depending on how it's used:

1private:
  float v[3];
  float mag;
4 
  void update_magnitude()
  {
      mag = sqrt(v[0]*v[0] + v[1]*v[1] + v[2]*v[2]);
      if(mag == NaN || mag > FLT_MAX)
          throw;
  }
11 
12public:
  void set_x(float x)
  {
      v[0] = x;
      update_magnitude();
  }
  void set_y(float y)
  {
      v[1] = y;
      update_magnitude();
  }
  void set_z(float z)
  {
      v[2] = z;
      update_magnitude();
  }
  void set_vec(float x, float y, float z)
  {
      v[0] = x;
      v[1] = y;
      v[2] = z;
      update_magnitude();
  }
  float magnitude()
  { return mag; }

If you use a vector's magnitude a lot compared to how often it's changed, it'd be more efficient to calculate it when the vector changes, instead of when you need it. Or optionally you could set a flag when x, y, or z changes and when the magnitude is requested, update it if it's "dirty".

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Tobias Dammers

Member #2,604

August 2002

Yes, if I needed the magnitude a lot between subsequent changes, then I would probably go for the "dirty" approach, which would of course involve getters/setters.

Quote:

And how would I avoid that using getters/setters? Can't I just lock / mutex / whatever the entire vector before accessing it?

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén