Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: 1
1
Off-Topic / EOMA68: Modular, freedom-respecting, and "Earth-friendly" computers
« on: August 04, 2016, 01:17:51 pm »
So there's an ongoing crowdfunding campaign which started last month:
https://www.crowdsupply.com/eoma68/micro-desktop
This video is worth watching as well:
https://www.crowdsupply.com/eoma68/micro-desktop/updates/hope-2016
This is a really neat, and possibly very important project. Basically, it's a standard where there's a small "computer card" holding the actual computer, and that plugs into any compliant housing. This means you can upgrade your computer very cheaply (keep the housing, just upgrade the computer card), and there are tons of possibilities that would be unthinkable normally.
First offerings are a computer card using the Allwinner A20 SoC (which, before you ask, is not GPL-violating), a "micro-desktop" wooden housing, and a 3-D printed laptop housing. The micro-desktop ends up costing a total of $120, while the laptop ends up costing $565 (or you can pay more if you want it pre-assembled for you). But because of the design of the standard, the $500 cost for the laptop housing is flat; when an upgrade is available, you just buy a new computer card for ~$50. You can even very cheaply have several different computer cards for several different purposes and just swap them out through the same laptop housing.
You can also get a set of cables to use an EOMA68 computer card without a housing at all, or a "passthrough card" that lets you use an EOMA68 housing (currently the laptop housing) as a peripheral (e.g. to add a keyboard and bigger screen to your phone, or to use the laptop housing for the screen, keyboard, and mouse of your desktop computer).
If this takes off, it can pave the way to solving the massive problems we have getting even remotely decent hardware for libre software today. I'm really excited about it (I backed it right away when I found out about it, then backed it a few more times after that), and I hope it succeeds! The campaign ends on August 26 and 41% of the funding goal has been raised as of the writing of this post.
https://www.crowdsupply.com/eoma68/micro-desktop
This video is worth watching as well:
https://www.crowdsupply.com/eoma68/micro-desktop/updates/hope-2016
This is a really neat, and possibly very important project. Basically, it's a standard where there's a small "computer card" holding the actual computer, and that plugs into any compliant housing. This means you can upgrade your computer very cheaply (keep the housing, just upgrade the computer card), and there are tons of possibilities that would be unthinkable normally.
First offerings are a computer card using the Allwinner A20 SoC (which, before you ask, is not GPL-violating), a "micro-desktop" wooden housing, and a 3-D printed laptop housing. The micro-desktop ends up costing a total of $120, while the laptop ends up costing $565 (or you can pay more if you want it pre-assembled for you). But because of the design of the standard, the $500 cost for the laptop housing is flat; when an upgrade is available, you just buy a new computer card for ~$50. You can even very cheaply have several different computer cards for several different purposes and just swap them out through the same laptop housing.
You can also get a set of cables to use an EOMA68 computer card without a housing at all, or a "passthrough card" that lets you use an EOMA68 housing (currently the laptop housing) as a peripheral (e.g. to add a keyboard and bigger screen to your phone, or to use the laptop housing for the screen, keyboard, and mouse of your desktop computer).
If this takes off, it can pave the way to solving the massive problems we have getting even remotely decent hardware for libre software today. I'm really excited about it (I backed it right away when I found out about it, then backed it a few more times after that), and I hope it succeeds! The campaign ends on August 26 and 41% of the funding goal has been raised as of the writing of this post.
2
Issues Help Desk / LateralGM seems to have just... stopped compiling?
« on: November 04, 2014, 07:29:08 am »
I'm trying to compile this with ENIGMA:
http://nintendocfc.com/uploads/userbooths/74/smgs_enginedemo_newcontrols.zip
But at some point, it seems to have just... stopped. No error or anything, it's just been sitting here supposedly doing something for an hour. I've tried three times with the same result.
This is the tail end of the output:
http://pastebin.com/fmGanyhi
There was also some stuff that didn't get sent to the text file I sent output to:
So, any thoughts? I'm not sure how to interpret this.
http://nintendocfc.com/uploads/userbooths/74/smgs_enginedemo_newcontrols.zip
But at some point, it seems to have just... stopped. No error or anything, it's just been sitting here supposedly doing something for an hour. I've tried three times with the same result.
This is the tail end of the output:
http://pastebin.com/fmGanyhi
There was also some stuff that didn't get sent to the text file I sent output to:
Code: [Select]
Gtk-Message: Failed to load module "canberra-gtk-module"
java.lang.IllegalArgumentException: Can't seek to 16,494 from 17006, position already passed (required skip: -512)
at org.lateralgm.file.StreamDecoder.seek(StreamDecoder.java:172)
at org.lateralgm.file.iconio.ICOFile.fillDescriptor(ICOFile.java:213)
at org.lateralgm.file.iconio.ICOFile.fillDescriptors(ICOFile.java:198)
at org.lateralgm.file.iconio.ICOFile.read(ICOFile.java:164)
at org.lateralgm.file.iconio.ICOFile.<init>(ICOFile.java:129)
at org.lateralgm.file.iconio.ICOFile.<init>(ICOFile.java:113)
at org.lateralgm.file.GmFileReader.readSettings(GmFileReader.java:429)
at org.lateralgm.file.GmFileReader.readProjectFile(GmFileReader.java:225)
at org.lateralgm.file.GmFileReader.readProjectFile(GmFileReader.java:165)
at org.lateralgm.main.FileChooser$ProjectReader.read(FileChooser.java:387)
at org.lateralgm.main.FileChooser$1.run(FileChooser.java:564)
at java.lang.Thread.run(Thread.java:745)
So, any thoughts? I'm not sure how to interpret this.
3
Proposals / Extend LateralGM's room editor to be usable as a generic level editor
« on: September 12, 2014, 04:08:16 pm »
I recently released a library called "ulvl", which defines some generic level formats that games can use:
https://gitorious.org/ulvl
The idea is, rather than level editors being directly tied to a particular game (as is the case for most level editors) or engine (as is the case for LateralGM's room editor), any game can read the format, and then game developers using any engine or graphics library can just get on with making their levels without having to make a level editor first.
I'm writing a generic level editor from scratch in Python, but thinking about it, LateralGM's room editor can fit the bill perfectly. Rooms could be saved as JSL (JavaScript Level) files very simply:
- Each LateralGM instance in the room can be a level object in the JSL file.
- The JSL file objects' IDs can be the "object" name in LateralGM.
- The JSL file objects' "option" values can be set to the LateralGM instances' creation code.
- The LateralGM room width and height can be assigned to a 2-value array "size" meta variable in the JSL file.
- Other room properties can optionally be assigned to arbitrary meta variables in the JSL file.
- The room creation code could be repurposed as a way to define other meta variables.
Alternatively, another format (maybe one based on XML?) could be added to ulvl, and then that could be supported by LateralGM.
Would anyone be interested in adding this option to LateralGM (to save and load at least one of the ulvl level formats)? I could probably do it myself, but I am very inexperienced with Java. It would be too big of a project for me. Someone familiar with Java could probably do this much more easily. However, I would be glad to define another format (e.g. one based on XML) if it's helpful.
By the way, I'd prefer this to be in the main distribution of LGM, not in a separate fork, if possible. Done correctly, this feature wouldn't interfere with LGM's usual work. It would just be two additional buttons and/or two additional menu entries.
https://gitorious.org/ulvl
The idea is, rather than level editors being directly tied to a particular game (as is the case for most level editors) or engine (as is the case for LateralGM's room editor), any game can read the format, and then game developers using any engine or graphics library can just get on with making their levels without having to make a level editor first.
I'm writing a generic level editor from scratch in Python, but thinking about it, LateralGM's room editor can fit the bill perfectly. Rooms could be saved as JSL (JavaScript Level) files very simply:
- Each LateralGM instance in the room can be a level object in the JSL file.
- The JSL file objects' IDs can be the "object" name in LateralGM.
- The JSL file objects' "option" values can be set to the LateralGM instances' creation code.
- The LateralGM room width and height can be assigned to a 2-value array "size" meta variable in the JSL file.
- Other room properties can optionally be assigned to arbitrary meta variables in the JSL file.
- The room creation code could be repurposed as a way to define other meta variables.
Alternatively, another format (maybe one based on XML?) could be added to ulvl, and then that could be supported by LateralGM.
Would anyone be interested in adding this option to LateralGM (to save and load at least one of the ulvl level formats)? I could probably do it myself, but I am very inexperienced with Java. It would be too big of a project for me. Someone familiar with Java could probably do this much more easily. However, I would be glad to define another format (e.g. one based on XML) if it's helpful.
By the way, I'd prefer this to be in the main distribution of LGM, not in a separate fork, if possible. Done correctly, this feature wouldn't interfere with LGM's usual work. It would just be two additional buttons and/or two additional menu entries.
4
Teamwork / I hate making user interfaces. Would anyone like to help me make an IDE?
« on: December 04, 2013, 05:48:38 pm »
I've developed a universal game engine for Python called the SGE ("Stellar Game Engine"). You can think of the SGE as an alternative to ENIGMA. It has a website here:
http://stellarengine.nongnu.org
I've been facing a huge problem lately, though: now I have to make an IDE for this, particularly a room editor. But the thing is, I hate making user interfaces. It's just not the type of programming I like to do. Because of this, development of just the room editor, which I've decided to call the SELE ("Stellarly-Encompassing Level Editor"), has been horrendously slow, and every time I go to it I feel overwhelmed before I even get started.
So, if anyone here actually likes making user interfaces and would like to help, please join in! I don't even care what libraries are used. Heck, I don't really care what language is used.
This is a lot more detailed, if you're into that kind of thing:
http://www.gamedev.net/classifieds/item/2613-ide-for-a-python-game-engine-ive-written/
http://stellarengine.nongnu.org
I've been facing a huge problem lately, though: now I have to make an IDE for this, particularly a room editor. But the thing is, I hate making user interfaces. It's just not the type of programming I like to do. Because of this, development of just the room editor, which I've decided to call the SELE ("Stellarly-Encompassing Level Editor"), has been horrendously slow, and every time I go to it I feel overwhelmed before I even get started.
So, if anyone here actually likes making user interfaces and would like to help, please join in! I don't even care what libraries are used. Heck, I don't really care what language is used.
This is a lot more detailed, if you're into that kind of thing:
http://www.gamedev.net/classifieds/item/2613-ide-for-a-python-game-engine-ive-written/
5
Issues Help Desk / [solved... er... and some unsolvable] ENIGMA not working on Trisquel
« on: November 28, 2013, 07:13:44 pm »
EDIT: Half the problem was solved, half was from a corrupt GMK.
Trisquel 6 is a variant of Ubuntu 12.04 with no proprietary software.
Unfortunately, when LateralGM tries to use ENIGMA to compile something on Trisquel 6, OpenJDK crashes. A log file is created, and it suggests reporting it on Ubuntu's bugtracker. (Also happens with OpenJDK 7.)
To reproduce, open this file with LateralGM (from the latest Git of ENIGMA): http://www1.datafilehost.com/d/98f24ae5
Press the "run" button. At some point during compilation, Java and LateralGM crash, producing a log file like this:
http://www1.datafilehost.com/d/a15354f1
I can't tell if this is a Trisquel bug, an upstream (Ubuntu) bug, or a LateralGM bug. Any thoughts? I'd really like to be able to use ENIGMA.
Trisquel 6 is a variant of Ubuntu 12.04 with no proprietary software.
Unfortunately, when LateralGM tries to use ENIGMA to compile something on Trisquel 6, OpenJDK crashes. A log file is created, and it suggests reporting it on Ubuntu's bugtracker. (Also happens with OpenJDK 7.)
To reproduce, open this file with LateralGM (from the latest Git of ENIGMA): http://www1.datafilehost.com/d/98f24ae5
Press the "run" button. At some point during compilation, Java and LateralGM crash, producing a log file like this:
http://www1.datafilehost.com/d/a15354f1
I can't tell if this is a Trisquel bug, an upstream (Ubuntu) bug, or a LateralGM bug. Any thoughts? I'd really like to be able to use ENIGMA.
Pages: 1