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 »
76
Tips, Tutorials, Examples / Modern OpenGL tutorial series
« on: May 21, 2013, 12:03:47 PM »
I found a new tutorial series about how to use modern OpenGL. There are current 3 articles in the series:

Getting started: http://solarianprogrammer.com/2013/05/10/opengl-101-windows-osx-linux-getting-started/

Drawing primitives: http://solarianprogrammer.com/2013/05/13/opengl-101-drawing-primitives/

Textures: http://solarianprogrammer.com/2013/05/17/opengl-101-textures/

The articles explain things bit by bit, and the source code for each program can be found on GitHub.

77
Proposals / Re: Manual, the Button
« on: May 17, 2013, 10:10:05 AM »
...whoops, I actually looked at that page earlier when checking that there indeed was no overview, guess I skimmed through it a bit too quickly :).

78
Proposals / Re: Manual, the Button
« on: May 17, 2013, 05:53:19 AM »
I agree about providing both an online and an offline version of the manual.

In regards to the form, I think the Wiki both has a lot of good content and is quite open for modification. One issue is that the Wiki contains both documentation for the development of ENIGMA, LateralGM and others, as well as documentation for using ENIGMA and the other tools for creating games. While this is not a big issue, it can make it more difficult for users to get the right search results when using the Wiki. Another issue with the Wiki is that it currently doesn't have a general overview for the different pages, as some of the previous GM manuals had. While GM:Studio has preserved some of this structure, they have decided to alphabetize the ordering of some of their content, meaning that the previous and meaningful order was lost. For an example of what I am talking about, there is this page for the manual for GM 7.0: http://gamemaker.info/en/manual. The section on GML has a good order, with basic parts first, and more advanced or niche parts later. I think both of these issues can be alleviated somewhat, by creating a Wiki page that contains an overview of all the user documentation, possibly with an format inspired by the GM 7.0 manual page, and then let the manual UI item in LateralGM link to that specific page.

As for the handling of the offline version, I think having a cached version is an interesting idea. I would like to suggest that an offline version is also bundled together with the editor, such that the user always have some sort of documentation available, even if it is somewhat outdated.

One potential reason for having a differently supplied manual is that we may or may not provide compatibility versions for old GM versions, which would be useful for games created for old GM versions. And in those cases, the manual for the given GM version would be useful to have. As for launching the given manual, I would suggest that we let the user specify a folder for documentation instead of launching a specific manual. That way, the user can put all their manuals and documentation in that folder, and we can just let the user/system choose which application to use to view the given documentation.

79
Supporting a particle system with 3D effects would be very useful to certain games. I don't think it would be easy to extend the current system to support 3D effects, but I do think I could refactor it into making it easier to support such an extension. I could well do that while I refactor the system to solve the current issues with it.

A particle effects designer would be very useful; there are particle effects designers for GM currently, but they are not cross-platform.

Being able to flip between different perspectives easily and according to what perspective the current game or room needs sounds very useful. I can also imagine being able to flip between them in a 3D game would be great when designing levels; getting an overview using the orthographic camera, and using the perspective camera when building the different rooms/sections.

In other news, most of the user-level constants, variables and functions have been moved to the enigma_user namespace. All the current extensions have been moved (except for the particle systems, which I will move after I have fixed and refactored them to the new system), the OpenGL 1.0 and 3.0 graphics systems have been moved, everything in Universal_System have been moved, OpenAL and FMOD music systems have been moved, BBox, BBox3d and Precise collision systems have been moved, and both the Linux and Windows code in Platforms have been moved. I haven't moved DirectX 10.0, mostly because it doesn't run yet, but it should be easy to move now that most of the other stuff have been moved, including the OpenGL 1.0 and 3.0 graphics systems. I have also fix a few bugs here and there, and I have refactored mathnc.{cpp,h} as well; Once the switch to enigma_user has been made, a couple of changes will need to be made there (basically just deleting and uncommenting a couple of lines and testing that it works).

Josh, in regards to the switch to enigma_user, I would like to request you to notify me once the switch is ready so I can try out the switching before it is implemented in the master branch. While most things have been moved, there may be some things I have missed, and so I would like to try and run some different games and tests to ensure that they compile and run, and fix any potential issues that occurs after switching, before the switch is committed to the master branch.

My plan for the future is right now to fix any issues that may crop up due to the move to enigma_user, and otherwise work on the particle systems.

80
Hey Robert, no problem, I have been busy with moving parts in other systems first, so I have only just now gotten around to it. I saw that you split it in two; providing a compatibility option for users is a good idea.

In regards to the particle systems, I am going to fix it after the namespace move is done and tested. I have some ideas for ensuring that the particle systems and the graphics system are not mutually dependent like I originally wrote it, but only that the particle system is dependent on the graphics system. I am thinking about putting the bridges (as in the parts of the particle system which is specific to a given graphics system) themselves in the particle systems, and ensuring that the graphics system is agnostic as to which particle system (if any) is being used. That would also be useful if we add more particle systems later and change the mechanism from an extension to a subsystem. A different way would be to make the graphics code in the particle systems independent of the graphics system, but I believe that better performance can be achieved if the particle systems can use code specific to each graphics system, so I am going to go in that direction.

And as a second heads-up, I have just moved the collision system, and I am going to begin moving the graphics system soon :).

That screenshot looks nice; will the user be able to put objects and move them around in 3D, and will the user assign each object a model instead of a sprite?

81
Just a heads-up to avoid duplicate work; I will begin moving the collision system user constants, variables and functions to namespace enigma_user soon.

82
Works in Progress / Re: OpenDave
« on: May 11, 2013, 05:05:38 PM »
Very nice. The game worked as it should, except for one bug; when standing at the door without having picked up the golden cup, the score goes up a lot. Apart from that, I didn't find any bugs.

83
General ENIGMA / Re: DirectX Graphics System Port *Forthevin*
« on: April 30, 2013, 06:07:03 PM »
Hey Robert, I don't know much about the Windows API or DirectX, so I don't think I can help you there. If you have trouble figuring out the Windows API, it may be a good idea to find a tutorial on it and follow it; understanding the APIs makes it much easier to work with them.

84
Robert, I think you are right that it primarily is moving function (and variable) declarations and definitions in the headers and sources into namespace enigma_user. All the functions that are directly available to the user should be moved to enigma_user. There are a couple of things to watch out for:

First off, when moving a user function, there may be other parts of the code that call that function. The fix is simply to prepend the call to the function with "enigma_user::", since the namespace for the function has changed and thus needs to be qualified properly. For code that already is in enigma_user, this should not be necessary, since calling functions in the same namespace does not require qualification.

Second off, be careful not to move any #includes into the namespace, since anything "included" will then be put into the namespace. Most of the time, this should just mean looking through the function declarations and definitions and moving all "includes" to the top.

There may also be issues with the hacks Josh mentioned before. There are a lot of user functions in the graphics systems, and I have just looked through it and haven't found any dragons, so I think that if you focus on moving user functions to enigma_user in the graphics systems and follow my guidelines, you shouldn't encounter any issues. If you do, let me know, and I will take a look at it.

As a side note, it should be possible to move the user functions little by little, so compiling and running frequently to verify that things work is a good idea.

85
Josh: Thanks for the heads-up, I will look into that later.

polygone: But that is what I did :). Though I guess I forgot to include that in the commit message.

Robert: Thank you, I am looking forward to spending more time on ENIGMA, it has been too long :).

86
No, they are actually available, I tested it myself. The solution is that I put:

Code: [Select]
namespace enigma_user {};

using namespace enigma_user;

in SHELLmain.cpp, such that the namespace is available to the users, like Josh instructed. That way, user variables/functions that reside in either the global or enigma_user namespace are available to the user.

87
I have moved some of the user functions and variables into the enigma_user namespace. I will move more later, but I will stay outside of collisions and graphics, to avoid moving things others are moving.

88
Works in Progress / Re: Mark the Penguin
« on: April 28, 2013, 12:20:09 PM »
I think the game is nice, though it has some warts and issues.

I previously took a look at the source code you posted, and the main suggestions I have is naming more of the resources, since that makes it easier to navigate the game source; as well as reducing the size of the really big backgrounds, which will make it easier for the editor and the game to handle.

In regards to the game, I think the core mechanics of the game are very nice; you walk steadily and slowly while on land, and swim much faster while in the water. And jumping out of the water is really cool. In certain cases, the jumps you have to make are really challenging, but if you are good at water jumping, you can also navigate the map much more easily, which is really nice. The breath resource means that you cannot spend too long underwater, and helps add to the challenge, especially when you are navigating under water and avoiding spikes and other obstacles and enemies.

I was in general a bit confused as to what to do sometimes. In the first map, I didn't know that I had to walk right (which I found out quickly though); in the second map, I was in doubt where to go, and searched through the under water caverns quite a bit. I then decided to try to water jump to the right over the spikes, which was the right way to finish. I think a bit more guidance, such as in-game control instructions (maybe a small text saying "click and hold left button to move" on the first screen), as well as some indication where the exit is (for instance a flag or a sign), would be a good idea.

The walrus was somewhat fast and difficult to dodge, though it was somewhat rare that I encountered it. Making it slower and easier to dodge could be a good idea, but since it is so fast, it doesn't take a lot of your health.

I encountered a bug when walking right in the start on the third map, so I didn't try the game out after that part.

89
Issues Help Desk / Re: Mark the Penguin [Weird Glitch]
« on: April 27, 2013, 12:16:50 PM »
Don't change the topic, make a new topic in WIP. If you post source or post binaries for Windows and Linux, people will be able to play it and test it. Btw., I have had a quick look at the game (haven't had enough time to look into the bug), and the game looks interesting, swimming, jumping out of the water, avoiding obstacles and not run out of air while under water. If you post to WIP, I will have some more comments, but the only one I will make right now is that the fourth line of the step event of the object "character" should be changed from:

Code: [Select]
if (collision_point(x,y,object38|object39|object40,1,1))

To:

Code: [Select]
if (collision_point(x,y,object38,1,1) ||
    collision_point(x,y,object39,1,1) ||
    collision_point(x,y,object40,1,1))

By the way, does the code collision_point(x,y,object38|object39|object40,1,1) actually work correctly in GM?

90
General ENIGMA / Re: Hardware Diagnosis
« on: March 29, 2013, 05:18:37 AM »
I can think of two ways to go about getting it to display all the text. In the terminal, there is usually a limit to how many lines it stores for viewing. This can usually be changed in a setting in the terminal. The second way is to redirect the output of "glewinfo" into a temporary file by using the following command in the terminal: "glewinfo > glew_paste". That redirects the output from "glewinfo" from the terminal output to the file named glew_paste. With all the output stored in glew_paste, glew_paste can simply be opened by some text editor (for instance "gedit"), and the content can then be copy-pasted from there.

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