Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 10 Nov 2005
Offline Last Active Yesterday, 07:27 PM

#5179972 Ever needed GLSL hilighting+autocomplete in Notepad++? Try this.

Posted by irreversible on 12 September 2014 - 03:06 PM

I wrote these about a year ago when I was having trouble focusing on other stuff and they've been lying in wait on my hard drive ever since. This is a hopefully complete autocomplete and syntax hilighting script for Notepad++ up to OpenGL 4.3, inclusive. See attached files.


Here's a copy-paste of the How To Use also present in userDefineLang.xml. Reading this is highly recommended since it may require some manual copy-pasting in case you're using other custom hilighting.

			-------  HOW TO USE -------
			1) installing
				- if you are using any other custom hilighting in Notepad++, then you need to
					copy the contents of this file *between the <NotepadPlus>* tags into your
					existing userDefineLang.xml
				  if you're not using any other custom hilighting, you can simply copy this file to
					the following location:
					Run Prompt (Win + R) -> %appdata%/Notepad++
				- the related auto-complete file needs to be copied to:
					[Notepad++ install directory]/Plugins/APIs
				  usually this is one of the following:
					C:\Program Files (x86)\Notepad++\plugins\APIs
					C:\Program Files\Notepad++\plugins\APIs
			2) using
				- once installed, GLSL will show up underneath "Define your language..." in the
					Language menu in Notepad++. Notepad++ needs to be restarted for the option to show
			3) enabling auto-complete
				- auto-complete may not be enabled by default in Notepad++. To enable it, run Notepad++,
					navigate to
					Settings -> Preferences -> Backup/Autocompletion
					and check the following:
					* Enable auto-completion on each input
					* Function parameters hint on input
					Leave the radio button on Function completion
			4) oh-oh, and if you don't have Notepad++, get it from here:
				- http://notepad-plus-plus.org/download/
			5) auto-complete function hints format
				- the auto-complete tips contain a lot of information that has been compressed into a small
					number of characters. Knowing the format will help with productivity and consistency.
					A generalized form of a hint is as follows:
					* DEPRECATED denotes that the entry is deprecated in the latest version of GLSL. Its
						use may or may not be possible based on GLSL's deprecation model
					* REQUIRED_MODULES (only present when relevant) can be:
					* MIN_VERSION notes the minimum GLSL (not OpenGL!) version required to use this entry
					* MAX_VERSION (only present when relevant) indicates deprecation
					* DOUBLE_MIN_VERSION is only present for relevant entries and may be set to '-', which
						indicates that while eligible, no double-precision overload of this function is
						explicitly defined

This isn't something I'm supporting or whatnot and it hasn't been error-checked by a third party, although tried to be as diligent as possible to weed out as many mistakes as possible.


I hope someone finds this useful.


Edit: note that the syntax hilighting is not complete - swizzle operators and such are a mess and don't parse well at all without context-sensitive information, which Notepad++ doesn't have. For general use it should suffice, though.


Attached File  glsl 4.30.xml   102.01KB   92 downloadsAttached File  userDefineLang.xml   11.86KB   74 downloads

#5179524 Exposing multiple objects to Lua from C++

Posted by irreversible on 11 September 2014 - 02:41 AM

I'm sorry to ask, but heaving read your post I still don't understand: what do you want exactly? What do you mean by 'support multiple exposed classes'? Do you mean many instances of the same class or many different classes?


Both. For starters I want to expose both IGame as kind of a "namespace" to enable access to the game's internal state and IEntity as two or more separate instances to expose the internal state of several different discrete objects.


I realize the former can be done with globals, but that wouldn't really solve the problem.


As for the question in the code - yes, lua_newuserdata will allocate a bunch of memory for you and it's garbage collected so you don't have to worry about it, if you free all C references (which is the only point of failure and possible leak of memory/object) and all Lua strong references are gone then the memory from lua_newuserdata will be garbage collected and __gc metamethod will be ran, if present. This is explained in great detail in Lua documentation.


Yes, I figured as much. I did read the docs as well. What is kind of confusing to me is that I can't reuse the allocated memory. I'm probably running into a simple entry level learning curve here, but it would be more logical to me if I could allocated the memory once (since I'm not storing a full object, but rather a pointer) and then change that pointer as needed while having a sense of transparency in terms of what memory and how much of it is allocated. Right now I'm having trouble seeing when exactly a leak will occur and when it will be collected.


Then again, I'm still struggling with the basics and the fact that I can't even explain what I want in detail means that I'm probably not really getting how things should work in the first place.


As for second problem in the code - why do you think IGame would/should be on the stack?


Ah - my assumption is that after


1) exposing IGame's metatable

2) and loading it in response to IGame:load() (which class loadGame())


it would be pushed onto the stack much like IEntity is right now. Apparently my assumption is wrong :)


I originally tried to write my own implementation for binding C++ to lua to learn the lua C api.  I got it mostly working for simple classes, but quickly gave up and switched to using a library because it would just take too much time to be able to support exporting any class generically with inheritance, constructors, different parameters, return types, etc.  


Not to discourage you from continuing to learn the api, but if you decide to give up like me and use a library, I'd suggest LuaBridge: https://github.com/vinniefalco/LuaBridge.


Indeed - that's the impression I've gotten as well. I'm probably going to migrate to a library soon enough - I guess my first problem isn't really what the code should look like, though, but rather how it should work in the first place. Thanks for the suggestion!


To your actual problem, when you call entity:AddModifier() from lua, lua pushes entity on to the stack (from the entity: part), which is why you could pop it from the stack in C++ with checkEntity(), however as FRex mentioned, the IGame object was never pushed on the stack within the call to entity:addModifier().  You would need to pass it in as a parameter.


Hm - how so?


As above, doesn't calling IGame:load() (which translates to loadGame() in C++) push it onto the stack. How would I make this work?



Basically I'm trying to implement a module-based structure whereby the available modules in a Lua script would be along the lines of:


Discrete objects, eg

IEvent and IEntity - any number of discrete instances depending on the event


Interfaced internal classes, eg

IGame - expose current game state

IUI - expose UI functionality


I would love to pass in discrete objects (things like events and entities) as function arguments while exposing interfaced internal classes as global namespaces.


Does this make sense or is my logic going down the wrong path?

#5177735 Implementing an efficient and powerful modding environment

Posted by irreversible on 02 September 2014 - 03:52 PM

First off, be forewarned that I haven't really done my home work - I haven't studied the capabilities, limitations and details of most modding environments out there and I'm probably pretty much unaware of the complexities of implementing one. I do, however, have a broadstroke idea of what I want to achieve.


First off, my target scripting language will most likely be Lua. That's the one I have some experience with and have found to be powerful and easy enough at the same time. That being said, your thoughts are welcome.


I haven't looked into too many games as I find myself pretty pressed for time these days, but the games whose capabilities I've come to respect include, foremost:on the UI side, World Of Warcraft and on the overall capabilities side, Skyrim.


The target capabilities of the modding system I have in mind are, in the order of importance:


- item/mob expansion packs, including custom complex weapon and item behavior

- world expansion via dynamically inserted elements

- AI scripts

- game-wide rule-based replacement of world elements

- full UI replacement/extension, including new layouts/windows 

- post-processing/shader effects


The last three are pretty much the least of my worries for now.


As for implementation, the most straightforward method I can think of is creating a hooking layer that can override or revert to default behavior based on the input. Mostly, this seems fairly simple:

void OnDamage(IActor * receiver, IEvent * source)
res = 0;

for each mod in ondamage_hooklist
  //call script
  res = ondamage_hooklist[i].ondamage(receiver, source);
  if(res != 0)

if(res == 0)
  OnDamageDefault(receiver, source);

This applies to any functionality that supports modding, eg resource loading, item equipping, firing, using, hitting a target etc. Each event simply includes references to the relevant internal structures. For periodic events, a mod can initialize a timer.


This is all fine and dandy - until it comes to UI and post-processing mods. This is also the main reason I'm staring this thread - I haven't done anything like this before and if moddability is anything like physics or collision, it would do well to consider a general plan of attack as early in the design phase as possible.


I'm assuming the simplest way to support custom post-processing mods would be to simply run them on top of the actual game loop - eg simply apply a provided filter shader after the frame finishes drawing.


However, modifying the UI seems fancier and much more resource-heavy - trapping draw calls on exising elements from within Lua is one thing, but it feels that doing this with brute force may easily prove fairly slow.


Overall, I'm not yet entirely sure where I'm going with this or what it is precisely that I need. I also can't find too much overly accessible information on the web with respect to how big games do it, which is why I'm asking for ideas, links, caveats, pointers and things to consider from you.

#5169610 good random permutation?

Posted by irreversible on 27 July 2014 - 04:01 PM

I'll throw in my minimalistic GLSL PRNG. I'm using this in my particle code, which requires very basic random inital values. I stole it from here and modified it to make use of the VAO's vertex ID to generate unique seeds for each particle. It uses two variables (fTime and iSeed) as components to calculate the initial seed when the shader is run. iSeed has to be set once (or it could be omitted), fTime is modified per-update anyway. Modifying the code to return a 32-bit integer should be trivial ;).

uniform float fTime;
uniform int iSeed;

uint seed = uint(fTime * 1000.0) + uint(gl_VertexID) + iSeed;

const float InverseMaxInt = 1.0 / 4294967295.0;

//returns a result in the range [0, 1]
float drnd()

    uint i=(seed^12345391u)*2654435769u;
    return float(i) * InverseMaxInt;


EDIT: you mentioned you need to map one 32-bit int to another, in which case you can simple pass the previous value in as the seed. As for whether the result is always unique, I cannot say.

#5163885 Exception handling, debugging a custom memory allocator and working with firs...

Posted by irreversible on 30 June 2014 - 12:48 PM

Ugh. Okay - I actually managed to catch the culprit after almost a day and a half of debugging and it turned out to be something that had worked for me for over a year! Apparently there's a small buffer overrun, which was leaking into the adjacent object in memory and this turned out to be one of those fortuitous moments where I had something to latch on to. Just for reference, in this case the overrun was corrupting the object's vtable, so I spent some time trying to get VS's data breakpoints working on it, but ultimately still had to set up debug outputs all over the code until I could hone in on the offending calls.


I would appreciate suggestions if there are more efficient methods or tools out there that would make catching something like this easier. Getting lucky with identifying the corrupt vtable is one thing, but tracking the bug down really should be easier than this...


@Eck - yeah, that's just hastily written code. The style discrepancy is simple forum negligence in this case :)

#5060241 Understanding graphics pipeline

Posted by irreversible on 08 May 2013 - 03:23 AM

This is the OpenGL 2.0 pipeline laid out graphically. Note that it's lacking newer features such as geometry and tessellation shaders.



#5059411 Blending problem

Posted by irreversible on 05 May 2013 - 04:01 AM

For a better explanation on why alpha blending during runtime is wrong in the first place, check this out.


PS - what's in the alpha channel of the textures and the that of the active color when blending?

#5058630 AABB touching convex polygon (3D Space)

Posted by irreversible on 02 May 2013 - 09:00 AM

Are you after speed or precision?


- precision: convex-convex polytope intersection can be tested by testing if a vertex of object A is behind all faces of object B. The test needs to be done both ways. If the objects' bounding volumes intersect, but no vertices are contained, a more elaborate (and costly) edge-polygon intersection pass must be made (again both ways). You can exit as soon as you encounter the first positive result. If all vertices of an object are behind the other object's faces, then the first object is wholly contained; note that the opposite is not, true, though and the test needs to be run with the objects swapped to get correct results.


- if you want optimal speed, but are willing to give up some precision, you can run a kDOP-kDOP intersection pass on objects' bounding planes. It's much cheaper, but depending on complexity, a kDOP may not necessarily wrap your concave mesh perfectly. Note that your cube is a 6-DOP and you can use an n-DOP for your convex mesh. Here's the code for a k-DOP/k-DOP intersection test (from Realtime Collision Detection):




int TestKDOPKDOP(KDOP&a,KDOP&b, int k){
//Check if any intervals are non-overlapping, return if so
for(int i =0; i<k/2; i++)
if(a.min[i]>b.max[i] ||a.max[i]<b.min[i])
//All intervals are overlapping, so k-DOPs must intersect
return 1;

#5058312 Artificial Intelligence

Posted by irreversible on 01 May 2013 - 09:26 AM

What is artificial intelligence? And what is the difference between human intelligence and artificial intelligence?


That's a mighty philosophical question for a game dev site :)

#5058289 Nested Projections & Transforms

Posted by irreversible on 01 May 2013 - 07:13 AM

In terms of transformations - I suggest providing the 3D scene its own transformation matrix stack and manage the GUI completely independently.


Note, however, that things get a little bit funkier if your 3D scene uses FBOs internally - just something to keep in mind.

#5058288 Nested Projections & Transforms

Posted by irreversible on 01 May 2013 - 07:08 AM

Yes, using an FBO provides a simple and elegant approach and is conveniently backwards compatible up to GL2.0 core. An alternative would be to draw your GUI elements on top of the 3D window every frame, or if you don't want to do that, using the stencil buffer or a discard mask when drawing the 3D scene.


For simplicity's sake, especially if you want to support all forms of shaders in your 3D scene (and you still want to do child/sibling window clipping on top of it), using an FBO is the simplest way to go.


You'd have the set up the FBO just like a regular window, set its viewport to the texture rect and just draw the scene. Don't worry about the texture copy - it's really cheap.

#5057430 Composing the concave hull of a textured sprite

Posted by irreversible on 28 April 2013 - 03:20 AM

For a point cloud, check this out.


Overall, holes are a real tough cookie to support unless you set up some rules: eg a hole can never intersect an edge. Otherwise you'll always have ambiguity, which cannot really be resolved. Also, if you increase your vertex count to one per pixel, you'll effectively be running marching squares on the shape, which should give you expected results if the shape doesn't fold back on itself and none of the hole edges/vertices are closer to the shape's edges than two pixels.

#5050589 Help me with which engine/development tools I could use to make this: (FPS)

Posted by irreversible on 06 April 2013 - 07:53 AM

Modern engine modding is very powerful (if not via visual node editors, then through proprietary scripting languages) so yes, you can do all of that and a lot more.

#5049830 Enum class : bitwise operations?

Posted by irreversible on 03 April 2013 - 11:18 PM

Here's what I'm doing to somewhat "automate" the process. You could write a macro to further cut down code.


enum ENUM_DrawElements : int {

static inline ENUM_DrawElements operator|(ENUM_DrawElements a, ENUM_DrawElements b) { return static_cast<ENUM_DrawElements>(static_cast<int>(a) | static_cast<int>(b)); }



You can now use bitwise or on members of ENUM_DrawElements: GD_DRAW_ELEMENT_STATIC_GEOMETRY | GD_DRAW_ELEMENT_ENTITIES | ...
NOTE: you do have to mind possible precision issues, though - casting to int is limiting the precision to 32 bits.

#5047211 Visualizing and writing algorithms

Posted by irreversible on 27 March 2013 - 07:06 AM

For me it's usually an iterative approach. I start simple and keep adding on components I get a full map (in my head or on paper).


Visualization comes with practice and to be honest the sentence "I can't visualize or write them off my head" doesn't make much sense. If you're working with simple stuff, then try to always get a picture of code flow in your head. If you have anything slightly involved, use pen and paper! It's the fastest and most flexible way. Sure, you'll end up drawing up examples for specific datasets in the beginning and spend some time making them look intelligible, but in the end it'll help you create a map in your head.


Visualization is a skill you can develop. If you "can't do" it, then you simply need to "do it" more. Sooner or later you'll start seeing patterns. If you want to be a painter, you need to first start painting :).