libMMS + V10phone, when technik hits miners.

Discussion in 'WIP and Development Status' started by V10lator, Jul 24, 2011.

Thread Status:
Not open for further replies.
  1. libMMS + V10phone, when technik hits miners.

    We got networks.
    We got displays.
    What next?
    Mobilephones in Minecraft!
    Work in process!

    Planned features for V10phone:
    • Optional CellMod support and if both olugins are enabled:
      • Show signal strength.
      • Show network name.
      • Custom network logos.
      • Disable CellMods commands for sending messages and the receiving of it and routing that actions through V10phone.
    • libMMS suppot and as such sending and receiving text and image messages from other people/plugins/progams on your V10phone even when you're offline.
    • Custom themes (desktop, menu design, clock, ...).
    • Optional: Show the in game time on the desktop with the help of lib24time (have a look in my Signature for a link).
    • Textured clock (on the desktop).
    • Ringtones.
    • In-Phone ringtone editor.
    What may get included is also:
    • Add custom applications to the mobiles (as other minecaft plugins or with a own plugin system).
    • Administrate your mobile through a web interface.
    • SIM-Cards.
    • Limited battery life (maybe rechargeable).
    • ...
    Here's a status update:
    • Splitted libMMS into libMMS and V10phone.
    • Added a frame buffer to V10phone.
    • Added font support to V10phone.
    • Added a Mobilephon-like menue to V10phone.
    • Finally fixed blockLights in the Camera part of V10phone.
    • Rewrote the Camera part from /mms commands / player.SendMessage(); to mobilephone actions / famebuffer output.
    • Added RAM and flash for applications.
    • Added Bootup "application" which uses the flash and the framebuffer.
    • Changed menu structure and integrated it better into the phones "fimware".
    • Added a harddrive.
    • Added "reset switch".
    • Added BluescreenOfDeath. :D
    • Added first bits of other usefull things. :D
    • Started rewriting the displayBuffe for windowed and fullscreen mode.
    • Added Background task (which executes every 32 ticks) to check the signal strength and lib24time presence.
    • Added debugging screen (so I don't have to write the whole path around a little thing to display it's output/state).
    Logs are still missing in the camera renderer. But the chance for a application API is really high right now. ;)

    Here are a few code snippets:
    Each mobile has a "operating system" running on it. This system gives some kind of API into
    the mobile which can (and should!) be used by custom applications. :D
    The "API" is very easy. Here's the applications RAM and flash:
    public HashMap<Object, Object> ram = new HashMap<Object, Object>();
      public HashMap<Object, Iterator<Object>> flash = new HashMap<Object, Iterator<Object>>();
    As you can see it's freely use- and adressable. Also each obile has it's own freeze switch which
    deactivates the menue:
    public boolean freezed = false;
    When a application get's loaded this switch will be setted to true. So the menue stops working
    on the "kernel API" and you can use the buffers, ram and flash like you want in your applications! But It's the job of the application to set this switch to false again right before returning. Also the application should clean up RAM and flash before using because it's not guaranted that they would be cleand up from the previous applications (even if it's recomended to do so, but that's the applications job...).
    As noted there are also some buffers:
    public final DisplayBuffer displayBuffer;
      public boolean keypadActive = false;
      public String keyBuffer = "";
      public byte touchBuffer = 0;
    The displayBuffer has it's own internal structure which makes let you do actions on the display easily. Here's a code example:
    mobile.displayBuffer.blank(false); // Blank the image in the buffer but don't update the screen.
    mobile.displayBuffer.text = "Hello World"; // Write "Hello World into the text buffer.
    mobile.displayBuffer.update(true); // Update the screen with the image in the buffer but render the text onto it before doing so.
    Of course you can also overwrite the buffered image with a image from a source of your choice, optionally render text onto it and flush that onto the screen:
    mobile.displayBuffer.image = (BufferedImage)myImage; // Overwite the image in the buffer with your own.
    mobile.update(false); // Update the screen with the image in the buffe but don't render text onto it before doing so.
    In the keyBuffer you will find input given through the chat. It get's filled when you activate a trigger in the mobiles "kernel". When you do so it will activate a lock and wait for user input, that means you don't have to read the buffer while the lock is active! Start a repeating task which reads the lock when it's released read out the buffer and work with the result.
    The touchBuffer represents the mousebuttons. It's called touchBuffer because it's primary use is to allow a quick access to actions printed on the screen. Have a look at the preview videos, then you see what I mean. ;)
    The touchBuffer is setted to 0 if no button was pressed. If the left mouse button was pressed it is 1, if it was the right 2. After you read out a value other than 0 it's your job to set the buffer to 0 again, otherwise you will read one keypress repeated forever (or till the user clicks the other mousebutton).
    There are some more tiggers and variables with usefull information and more will come. Maybe I will even add a scheduler for low priority background applications. :D
    Now there is a harddrive, too. With it you can save and read data over phone reboots. Please note that the file system has no security! Every application can read and write to all data stored on the disk. Harddrive access is slow and has an overhead. This bad design should prevent application devs to use the harddrive to often. The phones firmware stores it's data on that harddrive, too and even applications will get saved on it! But the system to bring the applications onto the drive doesn't exist yet...
    Here are some code examples:
    Code:"/path/to/my/file", "myFile.Name", "This is the content of my file.");
    mobile.fs.remove("/path/to", "The.File");
    Sting content ="/path/to", "the.file");
    Folders will get created and destroyed when needed. ;)

    Now we need a method to load applications from the disk and to kill them when needed, too.

    Today a V10phone registered at a CellMod network the first time! The displayBuffer needs to be rewritten for a signal icon on the phones upper information bar but since then a newly added debugging screen can show such usefull informations.
    The network strength is calculated the following way:
    If CellMod is not present: 100% (so CellMod is optional and phones will have signal without it installed, too).
    If CellMod is present but not woking (crashed for example): 0%.
    If CellMod is presented and working: Whatever it says. :D
    But we have only 4 stages and not 6 like CellMod itself. That's because the icon can show only that much.
    Hint: Custom applications which send data can (and should!) calculate their speed from the signal strength. Maybe the firmware will doing that for them...

    If anybody has a good looking, free font (and I mean good looking when it's really small) please give it to me because I'm still searching for the mobile's default font. ;)

    Preview Videos:

    Unset, muCkk and rakiru like this.
  2. I will push this now because I think 29 edits are enough and I think this thread get's lost and the most important changes wheren't noticed by anybody. :D

    • Changed the way the discplayBuffer works internally a lot.
    • Added and bugfixed fullscreen and windowed mode.
    • Changed Bootup screen, menue, camera application, ... to use fullscren/windowed modes.
    Now the displayBuffer has fullscreen and windows mode. What sounds like nothing special is an important thing: In windowed mode the phone shows (if lib24time is installed, too) a clock, icons for new Messages and the signal strength above the applications screen. Also the firmware renders "touchbuttons" under it. The text of these buttons is saved in the displayBuffer, too and freely changable fom the application.
    Applications can't call a display update anymore. The call still exist and has to be used for the applications window to be rendered but now the rendered image get's saved in a kernel buffer (not accessible from the application). This new kernel buffer will be read out every 5 ticks and checked against a copy of the image currently painted on the display. If the buffer changed the display get's updated. It's the applications job to be in sync with this 5tick refreshrate. If your application try to update the screen every 2 ticks don't wonder that frames will get dropped.

  3. Offline


    Looks AMAZING!
  4. Offline


    Looking cool and genius.
  5. Offline


    Wow seriously? :D I've been looking for a mail plugin but this seems even better :D
  6. Can you see the videos? :D
    It's still in an early developping state... Right now I'm working on the application system but that seems to be no easy task and I have other projects running which need my attention, too.
    Also there are some things going on in bukkit and it's (hopefully soon to be released) MapAPI. I hope the guys will find the best way for a nice and fast API the phones can use because the API it uses right now is just there till bukkits is ready. The rewriting for the new API will be probably hard, too (didn't had a look into it for now) but it will also offer speciall features like cursors... :D
  7. Offline


    Looks awesome! Video's are cool aswell :p
Thread Status:
Not open for further replies.

Share This Page