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.


Topics - Goombert

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
76
General ENIGMA / Sampler States and Texture Handling Poll
« on: July 16, 2014, 12:15:26 AM »
Please read the earlier topic for more discussion.
http://enigma-dev.org/forums/index.php?topic=2091.0

After some more digging, I found most of my initial assumptions are correct. Allow me to quote some various sources.

http://www.virtualdub.org/blog/pivot/entry.php?id=180
Quote from: DirectX vs. OpenGL
On the flip side, one of the more annoying aspects of OpenGL I've found is the tying of sampler parameters — filtering, addressing, mip map LOD bias, etc. — to textures. For a software renderer that modifies texture data for these changes, this makes sense, but it doesn't make sense for modern hardware where these are usually sampler states. It can also make sense if you consider them intrinsic to the texture, but that then breaks down if you want to do something beyond what the hardware can support. A high quality image processor really needs to support higher quality filtering than bilinear; bilinear filtering gives a really crappy gradient map. To do this, you have to emulate the higher-order filtering using lower-order filtering, and you run into the problem that if you ever need the same texture bound with different parameters in the same pass, you're screwed, because you only have one set of parameters on the texture. I do this when rendering bicubic in VirtualDub's D3D9 driver, and I can't port it to OpenGL because it's impossible to do so. I looked at the source for various OpenGL binding layers, and they all seem to emulate sampler states by pushing them into texture parameters. This sucks.

http://forum.unity3d.com/threads/setting-sampler-state.21442/
Quote from: Unity3D ShaderLab Threads
If you want to use the same texture with different filtering modes, and can't have some script executed in between, then yes, it does get tricky.

There's no separate sampler state in OpenGL (filtering and other modes are set onto a texture), so exposing it in D3D style is not easy.
The gentlemen in that post gave slightly misleading advice, OpenGL does in fact allow you to create sampler objects, but they are an extension and not officially core until 3.3

http://docs.unity3d.com/Manual/ComputeShaders.html
Quote from: Unity3D Manual
Texture samplers in compute shaders

Textures and samplers aren’t separate objects in Unity, so in order to use them in compute shader you have to follow some Unity specific rules:

    Either use same as texture name, with “sampler” in front (e.g. Texture2D MyTex; SamplerState samplerMyTex). In this case, sampler will be initialized to that texture’s filter/wrap/aniso settings.
    Or use one of “predefined” samplers; name has to have “Linear” or “Point” (for filter mode) and “Clamp” or “Repeat” (for wrap mode). For example, "SamplerState MyLinearClampSampler" - this will have linear filter and clamp wrap mode.

This goes back to my main premise, OpenGL did not properly abstract texture resources for being the low-level graphics API it claims to be. Now I am mostly in favor of going with a mix that allows you to create sampler objects in your own custom shaders and by default having texture information per-texture, but this is compatibility breaking. This means you would have to code each texture you want repetition for and each one you want to set the filtering of, unless you use a custom shader.

The choice is ultimately up to everyone else, as I really can't make up my mind on the issue, but I would like to see a sample of everyone's opinions.

77
Developing ENIGMA / Texture Handling
« on: July 07, 2014, 02:23:06 AM »
Well this is something that needed discussed a long time ago. OpenGL stores sampling information per texture without the use of the OGL3 sampler object extension approved by the ARB for that core version. Direct3D has done it with sampler objects and properly abstracted the concept since the beginning of time.

Now, with YoYoGames essentially building a cross-platform DirectX emulator ("ANGEL dust") they are basically sticking to sampler states. In fact, I don't really know who I hate more them or the ARB. Don't get me wrong I love a lot of things about Direct3D, but Microsoft is purposefully responsible for fucking up a lot of OGL, but this this fuck up rests on the ARB's shoulders.

Anyway, because of this, OpenGL1 needs a sampler state emulator object which I've already written and works fine, however Project Mario takes a 10fps hit. OpenGL3 needs further integration with its shaders and the extension sampler objects, which I've already programmed and I can not find my way through Harri's shaders to integrate. Direct3D9 is fine, in fact it and OpenGL1 have working texture filtering.

Based on these two functions my assumption is that YYG is going to make all of the texture stuff based on samplers unlike Unity3D which stores texture repetition information, filtering, and what not per-texture.
http://docs.yoyogames.com/source/dadiospice/002_reference/drawing/texture_set_interpolation_ext.html
http://docs.yoyogames.com/source/dadiospice/002_reference/drawing/texture_set_repeat_ext.html

They may also change their minds once they begin implementing proper mipmapping and things which they have indicated interest in doing.
http://gmc.yoyogames.com/index.php?showtopic=608392

At any rate, if they don't change which I don't believe they will I have begun coding everything this way. These are the proposed texture functions, however they are not all documented yet I haven't had time as I've been focusing on the coding.
http://enigma-dev.org/docs/Wiki/Texture_Functions

My suggestion is that my current pull request be merged into the OpenGL3 branch until Harri or myself has time to complete the OpenGL3 sampler object integration.
https://github.com/enigma-dev/enigma-dev/pull/770

A tutorial for the OpenGL3 sampler objects is available below.
http://www.sinanc.org/blog/?p=215

78
Developing ENIGMA / Command Line Interface
« on: June 20, 2014, 03:00:37 PM »


So I decided to do some testing and get the command line interface I started working and building an empty game. The program I have dubbed "emake" boots in less than 3 seconds initializing the library and all, and can compile and run an empty game in about the same amount of time. It is significantly faster than loading the IDE and building an empty game from there.

This has a lot of implications, you can build games without an IDE, you can build games much quicker, especially extremely large games like TKG makes. This also means we could significantly improve the performance of LGM working with large projects. This would be done by only loading the resource tree at startup, and loading and unloading resources or as you edit them or we could also just cache them.

This would allow someone like TKG to load a 100mb game much quicker, probably about 5-10 seconds, and build the game much quicker. The way we would accomplish building the game without loading it is by simply passing the file path of the project to the CLI and telling it to build the project.

A lot of these ideas are already utilized by Studio and it has many of the same restrictions that follow which are actually the same for most other IDE's. But we have some issues:

1) LGM does not have a guaranteed format, it lets you save and load from all formats.
2) This would require that you create the project directory when you want to make a new game, like in Studio, you couldn't get away with adding resources and saving later because the IDE has to have it on disk.
3) GMK is damn near impossible to optimize as a result of it being one giant ass file, you can't easily skip through parts of it and write a single resource.
4) You probably would not be able to build without saving your changes. I believe Studio has this same restriction.

Some possible solutions are the following:
1) Treat formats like GMK as an import/export where you can import a GMK but it will automatically be converted to GMX or EGM whichever format you choose.

Here are some benefits:
1) Faster loading times
2) Faster compile times
3) Less out of memory errors
4) Can build projects without an IDE
5) Makes it much easier for 3rd parties to write IDE's and other interfaces for the program

So the question is, does the cost outweigh the benefit? I am fairly certain most of you would say yes, but feel free to express your ideas on the matter.

*** Update ***
See latest forum post, the CLI now builds projects.

79
General ENIGMA / Indie DB and others
« on: June 18, 2014, 11:26:15 AM »
This is just a heads up to everyone, ENIGMA has now been accepted on Indie DB so if any of you make any games with ENIGMA and want to upload them there be sure to set our engine, "ENIGMA Development Environment"

http://www.indiedb.com/engines/enigma-development-environment

Feel free to add games, tutorials, reviews or whatever you like to our page. Also feel welcome to offer constructive criticism but please keep it appropriate.

I hope that this may create a broader awareness of our engine and potentially attract more developers.

80
Announcements / Timelines Implemented
« on: June 04, 2014, 01:31:52 AM »
That's right, timelines have been implemented by Seth N. Hetu (sorlok) in his quest to port Iji.

This was his pull request.
https://github.com/enigma-dev/enigma-dev/pull/738
This was the discussion topic about the implementation.
https://github.com/enigma-dev/enigma-dev/issues/636

You can get these changes via git or by downloading the new Portable ZIP.
http://enigma-dev.org/docs/Wiki/Install:Windows

Please test his changes and see how well everything works. And be sure to give him a round of applause for his contributions!

81
General ENIGMA / New Beginnings
« on: May 31, 2014, 10:13:52 AM »
Ok, there has been a lot of discussion of creating a fork of ENIGMA which actually fixes some things in GM. I am beginning to seriously consider this now.

The purpose of the fork is not to remain compatible with any other program, and takes the GM approach in a fundamentally different direction allowing for greater optimization and an intuitive redesign.

Some of the features and differences would be as follow:
* Windowing system would be completely abstract allowing the creation of multiple windows.
* No fake fullscreen, aspect ratio handled natively by the display.
* No view options in room editor and no global constants, views can be controlled via screen_set_viewport functions, because there is an efficient trick to speed up games by allowing two views to be rendered in the same draw call.
* Revamped non-retarded implementation of the audio_* functions.
* Complete redesign of graphics allowing not only vertex buffers but index buffers and instance geometry, with a proper bridge of OGL and D3D and not just a tacky way of emulating D3D by use of an OGL backend like ANGLE.
* Branching path system with improved A* motion planning.
* Cross-platform video interface for hardware accelerated video playback and rendering.
* All resources handled as included files, each will have a "preload" option and if it is unticked you have to load in manually using _load* functions asumming that all resources are extracted locally to the executable, but you will still be able to control how the resources are extracted, kind of like in Visual Studio
* Completely unrestricted file hierarchy, the IDE will also support loading multiple projects at once, and will support only one file format.
* Because the IDE will use a single uncompressed file format, the IDE will also be much quicker with loading and saving and compiling projects.
* CLI programs will exist for building projects outside of the IDE
* Non-object oriented method of compiling and linking code into your game.
* Possibly, strict C++, meaning no GML or EDL and no hybrid language, pure C++, variant type would remain most likely however, only differences would be more strict syntax, which ENIGMA kind of already has anyway.
* File reading/writing revamp, will support the ability to work with multiple INI files at once.
* Script redesign, they will be actual source files, if you want them to act like functions in GM you will have to prototype the function, not sure what to do about forward declarations.
* As a result of the script redesign, there will exist an object resource, but the object structure will be redesigned to allow you to easily and simply code an object using a script, so for instance if an object has a sprite it will inherit an object_sprite class, if it has a model it will inherit an object_model, if it has physics it will inherit object_physics, or a combination of these entities. An event listener and stack may be created similar to Java, C#, or Qt Also important to mention the object resource will not be removed, it will remain allowing a more graphical approach to create an object.
* Possible drag and drop redesign that will follow a more schematic approach like you often see with material/shader editors.
* Certain aspects may follow a more entity component style system, for instance, since views will be removed, you will be able to place camera/projection entities in the room to accommodate, which will also allow you to control aspects such as fog. Unsure of how to handle instance translations and properties however, as it will be dependent upon what entities their prototype class inherits.
* Full threading support, atomic and immutable types etc.

This project will basically allow us to address things immediately by doing them our own way, discussion of feature and implementations will not revolve around compatibility vs. incompatibility. These are simply ideas floating in the air, but I am seriously consider turning this into a practical implementation. I am just sick of working on something that I can't improve or innovate with. Suggestions and feedback is welcome. The project also has no name yet and is simply a proposal.

NOTE: This project would be licensed the same as ENIGMA once licensing for ENIGMA is established.

Just to put some names into the hat or some keywords to work with for a name:
Perform - not an acronym, pretty simplistic
Fluid or FLUID - possibly an acronym, meant to be intuitive, has no relation to F.L.U.D.D.
Formulate - key term, relates to variables/formulas/equations/functions

82
Developing ENIGMA / Win32 Nested Window
« on: May 25, 2014, 12:51:47 AM »
Well, I didn't realize until recently we are creating two windows on Win32, one is the child window for graphics and the top one is the parent. Our whole system is programmed around this currently by utilizing it to maintain the aspect ratio of the window since we use somewhat fake fullscreen behavior. This does however have its costs, 1 we can't use this solution for XLIB and Cocoa, 2 Win32 is buggy as hell on its own let alone trying to use a parented window device.

A simple solution that I already tested and got working was to remove it completely and handle window adaptation in the screen viewport function. glScissor was needed to stop the window color from becoming the room background color, so you would get black bars, but it did not work in fullscreen, Direct3D did not require any extra functionality because its viewports already treat them as bounds, but like OpenGL it also did not work in fullscreen.

At any rate, the only cross-platform solution is to emulate window adaption for our fake fullscreen behavior in the graphics systems/viewports. I want to know what everyone's opinion on this is.

83
Developing ENIGMA / Font Fractional Metrics
« on: May 19, 2014, 06:43:23 PM »
Well, after rigorous testing I have learned a lot of things about half-pixel alignment between Direct3D and OpenGL.

* You can not half-pixel align in the view or the bottom and right edges will be empty on the screen, or do similar for surfaces.
* You must add not subtract the pixel alignment in the projection function, if you subtract you'll get a similar issue to views.
* 0.25 appears to work the best in all cases, 0.5 may be driver/graphics card dependent
* OpenGL can not do a full half-pixel alignment (0.5) or games with repeating/scrolling backgrounds will skip and have a 1px gap sometimes between them.
* OpenGL and Direct3D pixel align differently, for instance, 0.25 is used in both systems, but when rendering text, you'll notice OpenGL has a space between lowercase 'r' and 't' whereas Direct3D does not, and Direct3D has a space between uppercase 'T' and 'Y' where OpenGL does not. One solution to this is to round up the glyph sizes in the font struct initialization.

NOTE: I used GM8 not 8.1, regardless of what the caption says, which did not have anti-aliasing options and by default used interpolation to render the font. And in ENIGMA I had the anti-aliasing disabled.



You can see GM8.0 renders the same as our Direct3D 9 system except it has interpolation because there were no aliasing options and it is turned off in ENIGMA. I used this code to test.
Code: (EDL) [Select]
draw_set_font(font0);
draw_set_color(c_black);
draw_text(0,0,"01234567890!@#$%^&*()_+-={}[]:;|\?/>.<,
QWERTYUIOPASDFGHJKLZXCVBNM
qwertyuiopasdfghjklzxcvbnm"
);

However, we still have the issue of the last bullet there. Because of font characters having fractional dimensions, they can still very easily become malaligned. The only solution I have thought of is to round up their dimensions, or else we need to find a way to truly fix half-pixel alignment.

Upon investigating the plugin I discovered that IsmAvatar has disabed fractional font metrics, which means subpixel accuracy. Or in other words the metrics should already be integer spaced.
http://docs.oracle.com/javase/7/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS
https://github.com/enigma-dev/lgmplugin/blob/master/org/enigma/EnigmaWriter.java#L687

84
General ENIGMA / EDC Partially Fixed
« on: May 12, 2014, 12:02:24 AM »
Since Josh won't make a post I will, after enough complaining from all of us and then me mocking him for a period of time he finally somewhat fixed the EDC. The download buttons now work again without a million errors showing up, however submitting games is still broke. I would appreciate if you would all continue to bitch and complain about it until he gets it fully finished.

Posting blogs should still be working just fine and dandy as well.
http://enigma-dev.org/edc/

85
Works in Progress / God of Man
« on: May 10, 2014, 10:51:56 PM »
Here is a small isometric game I had started working on when I was getting bored with Project Mario from a long time ago. Not much functionality as I had just started the game, but it was a remake of Age of Man which was a really awesome game made with GM6 that I once reviewed for Markup Magazine, only I planned to make the game more advanced and add an isometric view.



Download: https://www.dropbox.com/s/kauaugtvl6ceeko/godofman.gm81
Size: 2MB's

It works best under OGL1, but it runs faster under Direct3D9, only thing is D3D and OGL3 speed up and slow down constantly.

86
General ENIGMA / Debug Scoping and Other Fixes
« on: April 29, 2014, 08:59:56 PM »
I have made a round of fixes which you can see in this pull request.
https://github.com/enigma-dev/enigma-dev/pull/710

One of the main ones I have added is scoping for debug mode, it uses a stack and will print a full backtrace.

So now you will know where errors occur, it does not yet however tell you the name of an uninitialized variable, but it will in the future.

You can either git pull from master or download the new Portable ZIP.
http://enigma-dev.org/docs/Wiki/Install:Windows

87
General ENIGMA / Inheritance Fixes
« on: April 26, 2014, 04:55:02 AM »
So I have finally got around to fixing the remaining inheritance issues, mainly event_inherited now works inside all events including alarms, collisions, et all, I also fixed the No More Health event from firing more than once, it behaves as GM8.1 and Studio now. I also fixed the debug warnings in an empty game. I did these changes with the help of Josh, and he approves them as well. I have tested several individual cases to ensure that the fixes work, that none of the old behavior has broken, and that no new issues have arisen. I also tested on several EDC games and some of your individual games that you all have sent me over a period of some time.

To test these changes you can pull from master, or simply download the new Portable ZIP. If you encounter any issues as a result of these changes please notify me immediately and I will fix them right away.
http://enigma-dev.org/docs/Wiki/Install:Windows

I will also take time to respond to the rest of your bug reports later today.

88
Developing ENIGMA / Inheritance
« on: April 24, 2014, 03:46:45 AM »
* This post is for Josh, stay the fag out of it.

I have a couple of questions I need you to answer, I wrote everything the way you told me to, but there are a couple of things you did not consider. Please answer these questions so that I may continue working tomorrow and have most of it done by the time you get home.

1) How do I rewrite events.res?
Code: (YAML) [Select]
alarm: 2
        Group
: Alarm
        Name
: Alarm %1
        Mode
: Stacked
        Sub Check
: {alarm[%1] = (int)alarm[%1]; if ((alarm[%1] == -1) or (alarm[%1]--)) return 0; }
I rewrote that subcheck to look like this.
Code: (YAML) [Select]
Sub Check: { alarm[%1] = (int)alarm[%1]; return !((alarm[%1] == -1) or (alarm[%1]--)); }Also how should the following be rewritten.
Code: (YAML) [Select]
keypress: 9
        Group
: Key Press
        Name
: Press <%1>
        Type
: Key
        Mode
: Stacked
        Super Check
: keyboard_check_pressed(%1)

2) I had to make the non-stackable event base sub check methods virtual for event_parent since that is what the iterator is cast to in ENIGMA_events.
Code: (C++) [Select]
   for (instance_event_iterator = event_nomorehealth->next; instance_event_iterator != NULL; instance_event_iterator = instance_event_iterator->next) {
    if (((enigma::event_parent*)(instance_event_iterator->inst))->myevent_nomorehealth_subcheck()) {
      ((enigma::event_parent*)(instance_event_iterator->inst))->myevent_nomorehealth();
    }
      if (enigma::room_switching_id != -1) goto after_events;
    }
   
    enigma::update_globals();
This is what the virtual subchecks look like in event_parent, and yes I know inline virtuals are redundant, see the next question.
Code: (C++) [Select]
inline virtual bool myevent_draw_subcheck() { return false; }Also, why do we bother duplicating the subcheck code for every instance when it has to go through this many steps? Why not just write all the subcheck code that's needed for every instance to event_parent?

3) I had to write the grouped event bases like event_perform for now, are you alright with this?
Code: (C++) [Select]
// Grouped event bases
      void myevent_alarm()
      {
          if (myevent_alarm_0_subcheck()) {
            myevent_alarm_0();
          }
          if (myevent_alarm_1_subcheck()) {
            myevent_alarm_1();
          }
      }

89
Off-Topic / Environment Variables are Windows Only
« on: April 23, 2014, 03:40:25 AM »
Well I was recently fixing the environment_get_variable function for SuperRiderTH the old version was really messed up. But anyway, I just wanted to check Studio's manual for lols, and well...

Quote from: YoYoGames
NOTE: This is a Windows only function.
http://docs.yoyogames.com/source/dadiospice/002_reference/miscellaneous/environment_get_variable.html

Apparently YYG doesn't know that Unix invented environment variables, and is pretty much one of the biggest reasons Windows has them.
https://en.wikipedia.org/wiki/Environment_variable

Quote from: Wikipedia
They were introduced in their modern form in 1979 with Version 7 Unix, so are included in all Unix operating system flavors and variants from that point onward including Linux and OS X. From PC DOS 2.0 in 1982, all succeeding Microsoft operating systems including Microsoft Windows, and OS/2 also have included them as a feature, although with somewhat different syntax, usage and standard variable names.

I think this is the epitome of why their logic is so flawed.

90
Developing ENIGMA / Mega-textures and Atlasing
« on: April 22, 2014, 04:20:43 PM »
We've discussed this before, but basically ENGIMA needs texture paging/atlasing/s for mobile platforms that can't handle texture binding but have good video RAM.

We also currently do not have mega-textures for fonts, so you are limited to around a MAXIMUM of 500 characters, Harri just ran into this after testing the new Unicode font support because he set a really huge range for all his characters and didn't optimize it. The picture below shows how it could not fit all 555 characters he had set.



Studio also has the "used for 3D" option for textures and sprites which makes them their own texture, which is good for multi-texturing as well. Not much to discuss really, we just need to do it.

There is also an issue for this filed on the tracker.
https://github.com/enigma-dev/enigma-dev/issues/653

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »