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.
151
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".
152
Proposals / Re: Collision shape options
« on: October 09, 2012, 02:08:57 pm »
I think I understand the functions now. [snip]void *get_collision_mask(sprite* spr, collision_type ct)[/snip] 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 [snip]collisionsystem_sprite_data_create[/snip] is of the form [snip]char*[/snip]. 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, [snip]char*[/snip] 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:
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 [snip]collisionsystem_sprite_data_create[/snip] is of the form [snip]char*[/snip]. 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, [snip]char*[/snip] 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)
153
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:
The values of some of the arguments in the constructor call in the second file:
The content of /usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h, lines 1326-1329:
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 _GLIBCXX_HAVE_MODF 1
# define modf _modf
#endif
154
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?
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?
155
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.
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.
156
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"
"make"
Maybe executing the following commands before running "java -jar lgm16b4.jar" might help?
"sudo apt-get install zlib1g-dev libdumb1-dev libvorbis-dev"
"make"
157
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.
"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.
158
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.
159
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 (https://bugs.launchpad.net/ubuntu/+source/mingw-w64/+bug/1022397), 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.
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 (https://bugs.launchpad.net/ubuntu/+source/mingw-w64/+bug/1022397), 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.
160
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.
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.
161
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: http://imgur.com/a/AVdmU#0. They showcase the menu and some of the spells and enemies in action.
Source and binaries can be found here: http://www.sendspace.com/filegroup/ani1SmenRzIeh2HO9nVLeEGms0tQxFSY. 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.
162
General ENIGMA / Re: Liberated Pixel Cup beta-entry
« on: July 21, 2012, 09:48:57 pm »The changes will have to be reviewed, but most of them should be somewhat simple. Would pull requests on github be fine?
I have uploaded a new version, v47, which includes a new mode ("challenge mode"), an implemented credits section, and some installation + compilation instructions and a binary for Windows 7.
I originally tested the difficulty such that I would be challenged personally. Since I am probably what could be considered an expert player given my experience and knowledge of the game, I decided to make the new versions of the levels much easier, and keep the old versions in a sort of challenge mode. I also think that having a normal and very hard mode of each level is an easy way to make the replay value higher, such that people can try to beat those difficult levels once they have completed the normal game. I think it requires some more chapters before it will work well, however, such that people can get enough skill and experience with the game before they attempt the challenge levels.
Is the difficulty of the new levels appropriate?
Thanks again for your help. HaRRiKiRi, if you want to be credited as a beta-tester, I would be happy to add you to the credits.
163
General ENIGMA / Re: Liberated Pixel Cup beta-entry
« on: July 19, 2012, 03:44:40 pm »
I am very happy to hear that it looks good. I spent quite some time getting the animations set up properly and making the terrain. Most of the graphics is based on art from the LPC and opengameart.org.
I have purely used a fork of ENIGMA. Using data types is a good idea, and should be an easy option for optimization. I have had some performance issues when using larger views, which I believe is due to my Intel graphics card, but I am not certain.
I forgot to mention that the game won't compile using the main fork of ENIGMA. "get_sprite_idmax" is indeed one of the custom functions. I used a fork to ensure I could make quick bug-fixes, work around issues and extend ENIGMA. I hope to have some of the changes merged into the main fork after the competition, such that the game can be compiled without having to use the fork.
I have purely used a fork of ENIGMA. Using data types is a good idea, and should be an easy option for optimization. I have had some performance issues when using larger views, which I believe is due to my Intel graphics card, but I am not certain.
I forgot to mention that the game won't compile using the main fork of ENIGMA. "get_sprite_idmax" is indeed one of the custom functions. I used a fork to ensure I could make quick bug-fixes, work around issues and extend ENIGMA. I hope to have some of the changes merged into the main fork after the competition, such that the game can be compiled without having to use the fork.
164
General ENIGMA / Liberated Pixel Cup beta-entry
« on: July 18, 2012, 07:12:32 pm »
Hi everyone,
I have finished the first beta of my Liberated Pixel Cup entry. It is an action-shooter based on classic fantasy. It currently features one chapter, including 3 combat sections.
For those who are curious, I have prepared some screenshots, binaries for 32-bit and 64-bit Debian Stable and 64-bit Windows 7, and instructions for compiling on Debian Stable and Windows 7.
Screenshots can be found here: http://imgur.com/a/FNMmN#0. They showcase the menu and some of the spells and enemies in action.
The binaries and source can be found here: http://www.sendspace.com/filegroup/aOcpWEWHw12Vgs7avF8VPrsXDybIwZNEr27sgNJAoI4. 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.
EDIT: Instructions on running and compiling can now be found in the source. Added link to version 47.
EDIT2: See update post below.
I have finished the first beta of my Liberated Pixel Cup entry. It is an action-shooter based on classic fantasy. It currently features one chapter, including 3 combat sections.
For those who are curious, I have prepared some screenshots, binaries for 32-bit and 64-bit Debian Stable and 64-bit Windows 7, and instructions for compiling on Debian Stable and Windows 7.
Screenshots can be found here: http://imgur.com/a/FNMmN#0. They showcase the menu and some of the spells and enemies in action.
The binaries and source can be found here: http://www.sendspace.com/filegroup/aOcpWEWHw12Vgs7avF8VPrsXDybIwZNEr27sgNJAoI4. 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.
EDIT: Instructions on running and compiling can now be found in the source. Added link to version 47.
EDIT2: See update post below.
165
General ENIGMA / Re: Enigma and the Liberated Pixel Cup competition
« on: June 30, 2012, 10:26:59 am »
I tried compiling 32-bit from 64-bit Debian Stable, but it complained about incompatible libraries. Installing 32-bit versions of the libraries should solve the issue, but I am uncertain about how to do that properly in Debian Stable. I set up a 32-bit Debian Stable using VirtualBox instead, which took some time, but worked well.
I tried using the MinGW compiler descriptor on 32-bit and 64-bit Debian Stable. On 64-bit, there were packages missing in Stable that are available in Testing and Unstable, and on 32-bit, there were some issues with finding the right libraries (specifically, finding "ffi.h" and associated headers, since "ffi.h" was placed in /usr/include/i486 or somewhere similar). I think with further work the cross-compilation could be made to work in 32-bit Debian Stable.
In any case, thanks for the help. If anyone is interested, I have forked enigma-dev on github for the game, such that I can make quick fixes and improvements during the competition (some of the changes might be applicable to the main repository), and I may release some betas during the competition.
I tried using the MinGW compiler descriptor on 32-bit and 64-bit Debian Stable. On 64-bit, there were packages missing in Stable that are available in Testing and Unstable, and on 32-bit, there were some issues with finding the right libraries (specifically, finding "ffi.h" and associated headers, since "ffi.h" was placed in /usr/include/i486 or somewhere similar). I think with further work the cross-compilation could be made to work in 32-bit Debian Stable.
In any case, thanks for the help. If anyone is interested, I have forked enigma-dev on github for the game, such that I can make quick fixes and improvements during the competition (some of the changes might be applicable to the main repository), and I may release some betas during the competition.