Steam for Linux means Linux for Steam

Steam on Linux. That's a thing. It's coming. They have a naively running L4D2 working on Ubuntu using AMD's Linux drivers.

Steam on Linux has been "coming" for a long time. They've had job postings for Linux OpenGL developers for years. The reason why it's actually news now is because a member of the press was aloud to see Steam on Linux.

Valve is also working on a version of Steam designed to be used on a TV. That means UI designed for a lower resolution and to be controlled with something like a console controller (XBox controller is a Windows USB device).  They are going to great efforts to clone an console-like experience.

What we need is a distro of Linux Designed for Steam. Why? Because for most people, Linux is entirely to much effort.

Ubuntu answers most of those problems for day to day computer use.  If all you do is web applications and simple Office-style work, Ubuntu is a great Linux distro.

We need Ubuntu for gaming. We need a Linux distro that uses minimal background CPU and Memory, give games as much of the graphics card as possible, include Linux drivers for gaming level graphics cards, and as little else as possible. No OpenOffice, no ThunderBird, no IDE. Just a web browser, Steam, and an Ubuntu-like app-store to let people add what they'll use. It needs a UI designed for both Keyboard/Mouse and TV/Gamepad.

Valve could build this Linux distribution, and could even help push Nvidia and ATI to better their driver support, but more likely it would have to come out of the Linux comunity and, with Steam support, I can see the Linux community getting behind gaming in a big way if a company as influential as Valve pushed full native support for Linux.

If we had Gamebuntu... SteamBuntu, yeah, lets go with that. If we had SteamBuntu, then HP, Dell, Toshiba, Acer, Asus, or anyone else could build computers like we saw for early HP/Dell netbooks with Ubuntu.  We could see Alienware style gaming grade machines that ship with SteamBuntu instead of Windows. We might even see smaller formfactor systems designed like a modern game console that fit next to your TV.  These systems would ship working with Steam and all the drivers they need.

Valve has said that they are not planning on going into the hardware market any time soon, but they don't have to for there to be a ValveBox.

I not only think this is what should happen, but I think it will happen. Assuming Valve gets Steam on Linux by the end of the year (I know, maybe a bit too hopeful), I think we could see more game studios publish for Linux (we're already seeing that with many indie studios). Within a year or two we will probably see a version of Linux pre-configured with Steam. Assuming Linux For Steam becomes a popular alternative to Windows, we will start to see Dell or HP making gaming grade systems that ship with SteamBuntu (Microsoft will probably pay them to not do this for as long as possible, but that can't last if their is a large enough demand).

Still working on the NewLine... it's boring...

GameMath.h is getting more complex than I original thought it would get.  I'm working on ways to make it faster and I'm adding functionality to Line. I may divide it into a separate .h/.cpp per class to make it a little more readable.

Here's what it looks like now.

 //GameMath.h  
 //designed to handle all the 2D math  
 //involved in making a 2D game engine.  
 //I may pull out stuff like the line   
 //and intPoint class as seperate .h/.cpp  
 //for readablilty. That will depend   
 //on how complex this thing gets  
 //intPoint CLASS :D  
 class intPoint  
 {  
 public:  
      //default constructor  
      intPoint();  
      //constructor for x/y  
      intPoint(int X, int Y);  
      //add two intPoints  
      intPoint operator+ (intPoint B);  
      intPoint operator+= (intPoint B);  
      //subtract two intPoints  
      intPoint operator- (intPoint B);  
      intPoint operator-= (intPoint B);  
      //multiply  
      intPoint operator* (float Mult);  
      intPoint operator/ (float Dev);  
      bool operator< ( intPoint input );  
      bool operator> ( intPoint input );  
      bool operator<= ( intPoint input );  
      bool operator>= ( intPoint input );  
      //these are public since there isn't really   
      //a point to making them private  
      int x;  
      int y;  
 };  
 //line class  
 class line  
 {  
      intPoint Org;  
      intPoint Dis;  
      float M;  
      float B;  
 public:  
      //Intersection Stuff  
      bool SlideTo( intPoint* OUTPUT , line CD );  
      bool IntersectIntPoint( intPoint* OUTPUT , line CD );  
      //Change Values  
      line Shift( intPoint ShiftBy ); //Shift the point of org by a value  
      line SetOrg( intPoint MoveTo ); //set a new point of org  
      line SetDis( intPoint NewEnd ); //set new endpoint  
      //get fuctions  
      intPoint GetOrg();  
      intPoint GetDis();  
      float GetM();  
      float GetB();  
      //Constructors  
      line( line LineWith , intPoint newSlope );  
      line( intPoint Origin , intPoint Displacement );  
      line(); //base constructor  
      void Draw();  
 };  
 //region  
 class Region  
 {  
 public:  
      bool InRegion( intPoint C );  
 };  
 class BoxRegion : public Region  
 {  
      intPoint Org;  
      intPoint Size;  
 public:  
      bool InRegion( intPoint C );  
      BoxRegion( intPoint Org , intPoint Size );  
      BoxRegion();  
 };  
 class CircleRegion : public Region  
 {  
      intPoint Org;  
      int SizeSquared;  
 public:  
      bool InRegion( intPoint C );  
      CircleRegion( intPoint CenterPoint , short unsigned int Size );  
      CircleRegion();  
 };  

I was REALLY bored... so I wrote TheMemoryEater1000

I haven't posted anything in a while, so here is The Memory Eater: 1000. All it does it eat memory until it crashes... cuz yeah... why not. The 2000 version might have more features, but hopefully I won't be so bored I have to write it.

 //THE MEMORY EATER: 1000  
 #include <iostream>  
 using namespace std;  
 void CreateDumbMemory( int INPUT )  
 {  
      int KBToEat = INPUT * 1024;  
      for(int x = 0; x < KBToEat ; x++ )  
      {  
           new char[1024];  
      }  
      cout << "OMNOMNOM! (ate " << INPUT << "meg)\n";  
 }  
 void main()  
 {  
      int INPUT;  
      cout << "I am the Memory Eater 5000!\n\n";  
      do  
      {  
           cout << "Please Enter (in MegaBytes)\n"   
                "how more memory I should eat?\n:";  
           cin >> INPUT;  
           CreateDumbMemory( INPUT );  
      }while(INPUT);  
 }  

So, I may not be bored any time soon

http://www.cse.unt.edu/~sweany/CSCE3600S12/3600Syllabus.pdf
I'm working that that ^
so... it might be a while until I make another post.

I had two seconds, so I made an update

Lately I've been extremely busy and it's been a full week since the last time I posted an update, so I figured I'd post this saying that I haven't given up on this, I just have no time between helping with Minecraft, TX and school.

THIS IS STILL A THING!, I've just too busy to doing things lately. I'll be back! I'll finish the new Line class this weekend!

New "line" class

Prototype for new "line" class.

 class line  
 {  

      intPoint Org;  
      intPoint Dis;  
      float M;  

 public:  

      //Intersection Stuff  
      bool SlideTo( intPoint* OUTPUT , line CD );  
      bool IntersectPoint( intPoint* OUTPUT , line CD );  

      //change values  
      void Shift( intPoint ShiftBy );  
      void SetOrg( intPoint MoveTo );  
      void SetDis( intPoint NewEnd );  

      //Constructors  
      line( line LineWith , intPoint newSlope );  
      line( intPoint Origin , intPoint Displacement );  

      //Draw!  
      void Draw();  

 };  

This new version has two primary changes.

• I added a float for the slope (M).
• I converted the definition to be a point relative to the Origin and a Displacement relative to the first point.

I did both of these (and created the new constructors) to make polygon collision faster. My method of detecting if two polygons collide is based on drawing a line from each point of polygon A that represent the displacement, then you detect if those lines intersect with any line of polygon B. This means you are calculating the same slope (each displacement line) several times. If you make slope part of the line and build constructors that let you shift the point of origin you only have to calculate the slope once.

It doesn't make it easier, but it does make it faster. (I still don't know, however, if "faster" will even be relevant)

(ohyeah, and renamed Point to be intPoint because I might make a floatPoint someday)

Priorities

Ok, so I really need to figure out what I need to do next. SO, Imma make a simple billeted list of things to do with witch I will sort by priority!

HERE WE GO:

• redesign Line class (HIGH priority)
• Boxes (after LineClass)
• Polygons (more complex Box)
• Polygon Collision (fiction in Polygon)
• Sliding  collision (use of Line Class for sliding collision)
• Jumping Box "Game"! (use all that BS above to build a SUPER simple side scrolled)

EVENTUALLY: (maybe now, maybe later?)

• Build a full render system (work queues, window placements, zoom, pan, sprite handling)  (meh)
• Build a concept render system (window placement, zoom, pan)! (will make the thing above easier and make porting to a new engine easier [AGK] )
• switch to APK (gawgawgw)

The "eventually" stuff can be done at any point, but I'm going to procrastinate and push it way back... except maybe the "Concept Render System" (haven't decided on that yet).

edit:
also, I might might clone Tetris... but I don't think that will be my test tools for the Render System thingies.