switch and mp_step functions.

[MrGriggs]

I've been developing my rts and it's come VERY far now, I'm waiting on enigma to be ready to support everything within it, as stated in the topic title those are the two main functions, i'm planning on compiling and running this game with ENIGMA with an advert for it (I know advertising of it is against what josh encourages), it'll help a lot with getting attention for ENIGMA.

Then on the ENIGMA forums at the time, I will release a source and tutorial for my RTS system with commenting on how it functions, so please keep going with this project i has the faiths, functions imo are really important.

[Josh @ Dreamland]

I hate implementing functions, anymore. I much prefer just working on parser candy.

The worst part about this is that I had a discussion about mp_linear_step with a buddy not long ago, and I showed how an implementation of the function that performed -better- than Game Maker's could be written without an A* implementation (if only because Mark's A* implementation is a world-class failure).

Someone made a path plotting example in GM that used four different implementations; I think it would be neat if ENIGMA offered each of them to choose from.

The example I'm thinking of colored in all the tiles to show how it calculated the optimal path with the selected algorithm. If anyone knows which one I'm talking about, I'd appreciate if they indicated it to me once more (having a GM-friendly implemetation of these for at least reference would be a good thing).

As for switch, I guess it's about time I implemented that. I might just check if all of the case labels are literals to choose between C switch and GML switch, and screw the hash implementation.

Post made January 07, 2011, 03:13:16 am was deleted at the author's request.

[MrGriggs]

I'd realy like it asap, so I can see my engine running within ENIGMA and see how it performs, (Performs great for me on game maker but slower for some older systems), a move towards point function would even suffice for now.


Also, I'd like it if ENIGMA had a function to be able to draw a sprite to the background without having to do a large method, but only once that doesn't refresh so that it stays, this would be helpful for textures to the background that don't move.

[TheExDeus]

Also, I'd like it if ENIGMA had a function to be able to draw a sprite to the background without having to do a large method, but only once that doesn't refresh so that it stays, this would be helpful for textures to the background that don't move.

Surfaces are the thing you are looking for. I have tried to implement them (they actually where like 90% done, but because of some intel cards they commented the functions out), but I couldn't get them working because of headers which I can't make on win. I think screw intel and just make it work in opengl. If surfaces are not used, then automatically ENIGMA should exclude the headers.

[MrGriggs]

Yeah, but surfaces have a 1024 x 1024 limit as i've heard... I was using surfaces initially, but then read they have limitations

[TheExDeus]

Yeah, but surfaces have a 1024 x 1024 limit as i've heard... I was using surfaces initially, but then read they have limitations

Where did you read the limitations? The limitation is just the max texture size your video card supports. With my, now quite old, geforce8800 its 8192x8192 or even more. Usually its just how much memory you have. Even when the max limit is 1024x1024, you can still make several surfaces and work on them in tandem. I have used surfaces for extremely large rooms in the past.

Also, surface is the same as a texture. If you can't have a surface larger than 1024x1024, then you won't be able to hold a texture larger than that too.

edit: Here is a little demo on very large surface array. Sorry its 7.2mb, because I needed to include FMod.dll. My original milestone was to convert this to Enigma, but OpenAL doesn't support easy get_Spectrum functionality. Press O to see both channels and the part of the spectrum it looks for the beat.

[IsmAvatar]

functions like move_towards_point are very easy to implement in Definitions without the need of Josh. I'm sure anybody here with half a C++ brain could implement one for you.

[Josh @ Dreamland]

Go for it. Feel free to do the A* shit, because I don't really want to.

[IsmAvatar]

http://enigma-dev.org/forums/index.php?topic=727.new#new
move_towards_point peer review.

[MrGriggs]

When will move_towards_point be included in ENIGMA for official support? Surely all that's required is adding the function to the file then updating the SVN with that?

[Josh @ Dreamland]

You can just copy-paste it into "Definitions" under ENIGMA settings in the mean time, MrGriggs.

[IsmAvatar]

MrGriggs, the point behind peer review is that functions get reviewed by peers and improved upon before they get committed into the repository. This works any kinks out of them and ensures that they are up to efficiency specs, as well as making sure they don't break anything else. In the meantime, you may simply place the desired functions into Definitions, as Josh said.
Most notably, move_towards_point has been alleged to not even work properly due to degrees/radians issues, which could have led to a lot of unnecessary bug reports if it were already in the repository. Fortunately, peer review has alleviated that and helped diagnose and potentially correct this problem before it even makes it into the repo.

[MrGriggs]

Ok, thanks for the informative reply.