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.

Messages - forthevin

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 »
Announcements / Re: Commit Privileges
« on: October 23, 2012, 05:05:20 PM »
Thanks for the commit access, I am ok with fixing anything I break.

In case anyone is curious, my current plan is to continue implementing the precise collision system, which is coming along well (the basic collisions work, including rotation and scaling, some collision types are not fully supported yet, such as diamond and ellipse, and there are a number of other functions that are still missing). If anyone wants to try it out, select Enigma->Settings->API->Collision->Precise in LateralGM.

Proposals / Re: Collision shape options
« on: October 21, 2012, 01:30:23 PM »
I have just finished the patch, and it can be seen here: It has also been added to the existing pull request.

In regards to the interface change and the commit, I decided to change the interface from using char* to using unsigned char*, since that turned out to fit better with the existing systems. Apart from that, there was no other changes to the new interface.

Proposals / Re: Collision shape options
« on: October 20, 2012, 03:30:05 PM »
Unless anyone has any objections, I would like to go ahead and try to make a patch to implement the proposed changes. Since the changes regarding LateralGM and generic collision types are most useful once polygons or other collision types are supported in a collision system, I suggest that those changes are postponed until they are needed.

Proposals / Re: Collision shape options
« on: October 14, 2012, 08:55:54 AM »
I can't think of anything more that get_collision_mask should have, so I think it is good to go.

In regards to the mask system integration, I think it would be a good idea to support generic collision types in LateralGM, basically collision types that are identified only by their enum value and which has a generic representation (such as a byte array) for the collision data stored in each subimage. That would make it easier to support new collision types without making extensive modifications to LateralGM. It should still be possible to support a given collision type directly in LateralGM, for instance for the purpose of adding graphical editing for the collision type. Since adding graphical editing for generic collision types is not possible, LateralGM should support loading collision data for subimages from files, for instance by reading the contents of a file in as a byte array for a given subimage.

Proposals / Re: Collision shape options
« on: October 12, 2012, 06:11:24 AM »
Sorry about that, I can see how that could be confusing. The sprite struct I was talking about is the one in "ENIGMAsystem/SHELL/Universal_System/spritestruct.h".

Proposals / Re: Collision shape options
« on: October 09, 2012, 02:08:57 PM »
I think I understand the functions now. void *get_collision_mask(sprite* spr, collision_type ct) seems like it lacks a way to pass the collision system the input data for a subimage, since the sprite struct does not contain image data.

That brings up another issue, namely what to do if the collision type requires different input data than image data. For the majority of the collision types, image data works, but for collision types like polygon, the input data should ought to be vertex data rather than image data.

The current input data for collisionsystem_sprite_data_create is of the form char*. That works for image data, and I believe it could also work for vertex data as well as other formats. For instance, for image data, char* can be interpreted as it is currently, namely as an array of pixel-values, where each quadruple of bytes constitutes an RGBA-value, and where the size of the array can be calculated from the sprite's width and height. For vertex data, the first four bytes could indicate the number of vertices and therefore also the size of the array, and each following 2*4 bytes could indicate a vertex with (x, y) coordinates, each coordinate 32-bit.

The functions would then look like this:

Code: [Select]
void *get_collision_mask(sprite* spr, collision_type ct, char* input_data)
void free_collision_mask(void* mask)

Issues Help Desk / Re: Help me run ENIGMA on Ubuntu
« on: October 07, 2012, 06:38:18 AM »
I managed to reproduce the error using 32-bit Debian Stable (Squeeze) in a virtual machine.

I have debugged it a bit, and the segmentation fault seems to occur somewhere near the following two lines:

Code: [Select]
CompilerSource/JDI/src/API/lexer_interface.cpp: line 27.
CompilerSource/JDI/src/System/lex_cpp.cpp: line 1113.

The values of some of the arguments in the constructor call in the second file:

Code: [Select]
lcpp->filename: /usr/include/c++/4.4/i486-linux-gnu//bits/c++config.h
lcpp->line: 1326
pos-lcpp->lpos: 68

The content of /usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h, lines 1326-1329:

Code: [Select]
#if defined (_GLIBCXX_HAVE__MODF) && ! defined (_GLIBCXX_HAVE_MODF)
# define modf _modf

Proposals / Re: Collision shape options
« on: October 06, 2012, 04:04:47 PM »
Using enum constants for the collision type instead of a single integer field is a good idea.

I don't quite understand how get_collision_mask and free_collision_mask should work or be used. Does the collision mask returned from get_collision_mask only contain collision data for one subimage, or does it contain collision data for all subimages? Is it a linked list? What does free_collision_mask take as argument and return, and how should it be used in regards to setting the colldata?

Proposals / Collision shape options
« on: October 06, 2012, 10:32:31 AM »
Currently, the structure for sprites does not contain information for which kind of shape is wanted for a given sprite, such as bounding box, precise, ellipse, diamond or polygon mesh.

I propose a simple system, where a single integer field, for example "collisionshape", is used as an enum, and where each value indicates a given desired shape, for example:

0: bounding box

1: precise

2: ellipse

3: diamond

4: polygon mesh

Different collision systems can interpret the wanted shape differently. The BBox collision system can for example always use bounding boxes independent of the wanted shape, and a polygon collision system could model bounding boxes, ellipses and diamonds as polygons internally and ignore the precise shape. I think this is fine, because a collision system cannot handle a shape it does not support anyway, and it is very easy to change between collision systems. Basically, game developers should pick shapes that fit the collision system they use for a given game.

Issues Help Desk / Re: Help me run ENIGMA on Ubuntu
« on: October 06, 2012, 09:30:13 AM »
I recently installed ENIGMA on a fresh 64-bit virtual machine with Ubuntu 12.04, and I experienced no problems apart from some dependencies.

Maybe executing the following commands before running "java -jar lgm16b4.jar" might help?

"sudo apt-get install zlib1g-dev libdumb1-dev libvorbis-dev"


Announcements / Re: What needs said
« on: September 03, 2012, 12:02:03 PM »
The latest version of the jdi-branch still works well under 64-bit Ubuntu 12.04, apart from the true/false issue.

"Ability to export to any language from the backend." Does that mean, in theory and with enough work, JDI could export to JavaScript?

"Ability to declare getters and setters on certain variables." and "The possibility of adding quad trees to collision systems by placing setters on x and y." is great, and should help speed up collisions a lot.

General ENIGMA / Re: Enigma and the Liberated Pixel Cup competition
« on: September 03, 2012, 10:33:31 AM »
I have added a new wiki page called "Cross-compilation", and added my most recent findings. 32-bit compilation may potentially be easier than I thought, but I still prefer using a VM.

General ENIGMA / Re: Enigma and the Liberated Pixel Cup competition
« on: August 16, 2012, 04:20:22 AM »
Sorry for the very long response time, I ended up using virtual machines in order to compile for Windows and Linux 32-bit. That also allowed me to test that the compiled game worked as it should.

In regards to 32-bit libraries, it seems like compiling from 64-bit to 32-bit is considerably more complicated than from 32-bit to 64-bit. Since it is easy to setup 32-bit Linux in a virtual machine, this is not a big issue.

I tried cross-compiling for 64-bit MinGW using the jdi-branch on 64-bit Ubuntu 12.04. The two libraries that are missing are zlib and ffi. According to this link (, the zlib library seems like it is going to be included within the next couple of months, which solves that part. As for ffi, I remember working with ffi and trying to get that to work on Debian Stable, but I didn't get very far. Maybe someone who's better at setting up toolchains and stuff can figure that out.

All in all, using virtual machines is a little more bothersome initially than cross-compiling, but it seems like it is easier to get working, and it also enables testing on those platforms. The only issue with that is Mac OS X, which requires either doing illegal and fragile stuff with Hackingtosh, or getting Apple hardware and compiling it there. But that seems more like an issue of Apple sucking than anything else.

As a side-notice, getting the 64-bit Debian Stable binary working on 64-bit Fedora 17 was easy, and only required yum-installing 3 libraries and making a single symlink (the libdumb .so had a different name on Fedora than on Ubuntu).

Finally, thank you for your work on the jdi-branch, it makes things much easier.

General ENIGMA / Re: Liberated Pixel Cup beta-entry
« on: July 30, 2012, 02:27:10 AM »
I have added another chapter and some story. The levels are somewhat harder than the levels of chapter 1, and should take more time to beat.

The story is classic fantasy. The story is mostly conveyed through dialogue and the environment. I have tried to keep the amount of exposition low, to avoid information dumping, while still keeping enough to make sense of things and give the protagonist a reason for exploring and fighting. I have also tried to keep the story somewhat open, such that it can be changed and expanded upon later.

I have only made changes to the engine, as well as events.res.

Again, thank you for your help. I think this is how the submission will look like, apart from dialogue changes, documentation and bug fixes.

General ENIGMA / Re: Liberated Pixel Cup beta-entry
« on: July 30, 2012, 01:28:25 AM »

UPDATE 2012-07-30:

I have finished the final beta of my Liberated Pixel Cup entry, version 67. It is an action-shooter based on classic fantasy, and features two chapters, with 6 combat sections as well as a story.

Screenshots can be found here: They showcase the menu and some of the spells and enemies in action.

Source and binaries can be found here: The Debian binaries require some libraries to be installed, but should work on both Debian Stable as well as Ubuntu 12.04. The source can currently be compiled on Debian Stable and Windows 7.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 »