MotorJ progressing... 1.1 almost ready! - 11/11/2007, 23:37

Indeed, MotorJ has been delayed about 15 days from the last expected time of release published in this blog. But today it gave a gigantic step forward -- now I can really say it's almost ready: I added Object Oriented Programming to a specific case where I see lots of benefits (since my policy is to use OOP _only_ where and when it makes sense - that's why I hate Java, Java's policy is "OOP or bust").

Currently, there is only one class in MotorJ - The "Universe" class.

The Universe class is basically an abstract class which has a few functions declared as virtual, therefore, it is something like a reference and it will enable people to avoid having to mess with the engine code (you can still do it, of course, and it is encouraged, but it will definitely help beginners not having to worry over specific OpenGL/SDL initializing stuff). The "main universe" implemented in MotorJ does not follow the reference (it isn't even a class), but that's because the other universes run inside the "main universe": the main universe calls the current universe's relevant functions each frame (for example, the Update function as well as Redraw) and switches between different universes when asked to. Previously there existed only one universe, so trying to place a menu to choose options would result in extremely messy code. Now it's possible to have as many universes as needed, so from a "menu" universe it is possible to jump to the "single player game universe", or to the "multiplayer universe", or exit the application, or whatever you like :)

It is implemented in a way in which you can choose to leave an universe "paused", go into another one and return to the one you had "paused". And with the flexibility of OOP (and a special linked list I made, which btw is also a likely candidate to objectification), you could still call the Redraw function of the paused universe, and so you could draw an in-game menu overlaid on the game universe.

So let's see how I implemented the Universe class:

class Universe
{
 public:
  virtual void Init(app_ctl * app_data) {};
  virtual int ProcessEvent(s_event & event) {};
  virtual void Update(float t_trans) {};
  virtual void ReDraw(void) {};
  virtual void CleanUp(void) {};
  bool mustInit;
  bool mustCleanUp;
  Universe * NextUniverse;
 private:
  app_ctl * appdata;
};

And now let's look at part of the code running in the main universe's loop:

Universe * CurrentUniverse;
/*
* ....
*/

while (CurrentUniverse->NextUniverse != NULL)
{
 
  while (CurrentUniverse == CurrentUniverse->NextUniverse)
  {
   t_cyclestart = SDL_GetTicks();
   SDL_PollEvent(&ev);
   translate_event(ev,&event);
   CurrentUniverse->ProcessEvent(event);
   
   t_current = SDL_GetTicks();
   t_elapsed = t_current - t_previous;
   t_previous = t_current;
   
   CurrentUniverse->Update(t_elapsed);
   
   if (app.video_sup)
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
   
   t_previous = t_current;
   
   CurrentUniverse->Redraw();
   
   if (app.video_sup)
    SDL_GL_SwapBuffers();
   
   
   t_sleep = SDL_GetTicks() - t_cyclestart;
   if (t_sleep < t_maxsleep)
    SDL_Delay(t_maxsleep - t_sleep);
  }
  
  
  switch_universe(CurrentUniverse, &app);
}

Ok, so there it is: the universe class' functions get called in the loop. And each universe subclass is free to implement it as needed. So lets see a sample universe subclass:

class MenuUniverse : public Universe
{
 public:
  void Init(app_ctl * app_data);
  int ProcessEvent(s_event & event);
  void Update(float t_trans);
  void Redraw(void);
  void Cleanup(void);
  bool mustCleanup;
  bool mustInit;
 private:
  app_ctl * appdata;
  cam_ctl camera;
};

OK! so this universe subclass has an additional variable called "camera". And it won't conflict with another universe subclass' camera, because it is part of the MenuUniverse subclass :)

Much nicer than before, having those nasty pseudoglobal variables..
(and we can kiss the "error in socket( )" SIGSEV from a previous blog post goodbye, too :D)

So, here's motorJ's current (internal implementation, nearly ready for comitting to the repo) status:

- Most function calls translated to English
- Many comments and function parameters still in Spanish :S
- All data structures translated to English (hopefully :P, I need to check thoroughly)
- Special linked lists implemented (The 'deleting'/'empty' functions still need to be checked, though)
- 'Universe' class, no need to mess with internal code (still -and always will be- encouraged though)
- ProjectOvejota implemented (Loads .OBJ files along with square BMP textures - still missing: loading other formats via SDL_Image, as well as the ability to load non square textures, not much of an issue using glu's mipmapping function)
- TextRender text->texture implemented (blended mode only; still lacks \n functionality and fixed width auto adjustments, but it works)
- Many universes possible via Universe subclasses
- SDL_Net, SDL_TTF, SDL_Image needed and used.
- Spanish HowTo updated: lids

Desired before release:
- Missing features from previous list, implemented

Vital before release:
- Making sure NO functions are left in Spanish. Otherwise people's code will break with next release :S
- Code cleanup

Very important (vital though it won't delay release):
- Documentation in LIDSOL wiki!!
- Reviewing (yet again) the Installation howto and translating it to English -- especially for DevC++, current DevPaks seem to mess everything :(

Desired features for next releases:
- OpenAL
- Linked list objectification

Oh, and I forgot..
- C++ Classes: http://www.cplusplus.com/doc/tutorial/classes.html
This page saved me from yet another huge time-waster: http://www.wellho.net/mouth/802_undefined-reference-to-typeinfo-C-error-message.html (undefined reference to typeinfo - C++ error message)

Edit: Sí, ya vi que se ven ABSOLUTAMENTE FANTÁSTICOS los nbsp;'s en planetalinux.org, lo corregiré pronto T_T



< Back to blog

This site doesn't use cookies, does not log IPs and does not track you in any way.