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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »
1726
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 23, 2010, 05:43:46 pm »
Well queues need memory (in best case a vector that can autoresizes) and speed, well, because it just needs all this. Maybe the impact wouldn't be that big, but who knows.
I agree about the timer thing, and it would kick ass. But the draw{} thing just seems very problematic. Maybe Josh came up with some biblical idea that will blow our minds, but will see.
I agree about the timer thing, and it would kick ass. But the draw{} thing just seems very problematic. Maybe Josh came up with some biblical idea that will blow our minds, but will see.
1727
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 23, 2010, 05:10:43 pm »
There is reason why GM can draw only in draw event you know... For example, if object1 has depth=0, and another object2 has depth=2. So the first object1 draw event is executed before the second one and thus draws on top of the other. Now what happens when object1 draws in step event? It will draw below the object2 even thou it should draw on top. This can be fixed with some kind of queue, but that seems just like another way to lose memory and speed. Thou Josh can prove me wrong and get this done for the next rev, so I can snuff my coke in amazement.
1728
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 22, 2010, 08:02:56 am »Quote
5. Pausing The GameI usually just use room_persistent and move to another room. Very easy to implement, cool effects possible (like drawing the frame to a global surface and then blur it in the background in the pause room) and works great.
Quote
I've been chewing on this issue for tears.Don't cry. Everything will be o..... *died*
1729
General ENIGMA / Re: Some common GML issues, will/how can they be dealt with in Enigma?
« on: December 21, 2010, 04:22:21 pm »Quote
The problem with nth type functions is that they will be a lot slower to cycle through instances.Well you will always need to cycle trough all the instances. Its the only way to actually get the distance of thous instances (unless the room is divided in some regions and only instances in specific regions are checked etc.).
Quote
2. The function is able to cycle through instances itselfWell C++ is possible to return multiple values, and automatically populating an array or some ds could also be possible.
Quote
Yes like that, again I don't have all the answers.No I just wanted to understand what you actually meant. For example:
Code: (C++) [Select]
sprite_index="spr_player"; //this would not be good, because you can't actually return "spr_player" in this case. So context sensitive parsing could do this while compiling, but not real time.
sprite_index=sprite_get_string("spr_player"); //this on the other hand could be cool. Especially when some simple loops are necessary
1730
General ENIGMA / Re: Some common GML issues, will/how can they be dealt with in Enigma?
« on: December 21, 2010, 03:03:32 pm »Quote
1. Referencing multiple instancesAnd how exactly the return value would look like? If you just thought something like instance_nearest_nth (which would return n'th nearest instance) then that needs just a separate function.
Quote
2. Referencing resources as stringsAs string? Like "sprite_player" would return a sprite index? But then how would you write "sprite_player"? If you thought something like sprite_return("sprite_player"), then I think that could be possible, but in the same way as variable_set or execute_code.
Quote
3. Exiting CodeWhat do you mean with "entire code"? Do you mean the event? If so, then I guess it could be cool if you could stop the rest of the event to be executed. But to exit from code in any place you can just type "exit;".
1731
Announcements / Re: Scalability
« on: December 16, 2010, 05:17:49 pm »
I think Wiki's editing should be allowed only when signed in. There is vandalizing starting to happen.
1732
Proposals / Re: Random speed ups and slow downs with compiled games
« on: December 16, 2010, 05:15:43 pm »
Is ENIGMA forced with vsync? Because I actually wandered why I get only 76-81fps with that example where there is nothing going on. Only three lines of code. I went to my curve's example's last room where there is much more calculations and drawing and I got the exact number which jumps exactly between 76/81Fps. I have 75Hz, and ENIGMA's fps variable is known to be unstable (where FPS itself is not). So FPS could in reality be limited to 75Hz.
1733
Proposals / Re: Random speed ups and slow downs with compiled games
« on: December 16, 2010, 08:16:48 am »http://www.megaupload.com/?d=FWK4D7AZThat is also smooth for me. Thou I don't get 400fps, but only 76/81, but quite constant 76/81. That counter can jump between the two numbers, but the fps in the game itself is more constant. So I don't experience any large slowdowns/speedups. And didn't you mean:
Here is an exe where the fps is displayed and is most noticeable with the slowdowns.
Strange how it stays cleanly at 400, then drops to 100 and stays at that cleanly, then back up without jitter...
The only code in this game is thisCode: [Select]x+=1
if x-128>room_width x = x=-128
room_caption=string(fps)
In the "normal step" event.
if x-128>room_width x = x-128
1734
Proposals / Re: Random speed ups and slow downs with compiled games
« on: December 15, 2010, 06:44:25 pm »
Also, I am too not able to compile the source. It just froze at parsing. Josh should take a look at that.
But I did run your posted exe and I don't experience any speed difference. Jumped and moved around for about 3 minutes and it seemed to go the same speed all the time. You should of added: room_caption=string(fps) somewhere in step/draw event, because I don't know if FPS dropped, I can just tell you that it seemed smooth to me.
But I did run your posted exe and I don't experience any speed difference. Jumped and moved around for about 3 minutes and it seemed to go the same speed all the time. You should of added: room_caption=string(fps) somewhere in step/draw event, because I don't know if FPS dropped, I can just tell you that it seemed smooth to me.
1735
Proposals / Re: Random speed ups and slow downs with compiled games
« on: December 15, 2010, 06:37:02 pm »
You could of just added the source as an attachment. They are small enough to be allowed. I waited a whole minute just to get downloading.
1736
Proposals / Re: Random speed ups and slow downs with compiled games
« on: December 15, 2010, 10:54:28 am »
Can you give us the .gmk/.gm6/.gm7 so we can test it too? I haven't experienced any slow downs or speed ups. Its sound like you don't have limited room speed (fps) and so it runs as fast as it can (which can also cause slow downs, or at least seem slow compared to running lightning fast).
1737
Function Peer Review / Re: clamp()
« on: December 14, 2010, 01:38:34 pm »
Thanks. Didn't know that. I did use median for a different purpose, and having up to 16 arguments (in GML) didn't help me get the idea either.
1738
Function Peer Review / Re: clamp()
« on: December 14, 2010, 11:14:51 am »Quote
You mean median()?No he means clamp(). There is no equivalent in GM. It returns "lowest" when x<lowest, and highest when x>highest, and x when its between the two. Dunno if serpex's method is better thou. Because using at most two if cycles could be better than using always two function calls.
1739
General ENIGMA / Re: Cross-compiling
« on: December 12, 2010, 02:00:25 pm »Quote
I'm not seeing it either.Me too, dunno what Josh meant. I guess "Definitions" or "Initialization". Also, do any of thous settings/buttons do anything?
1740
General ENIGMA / Re: Cross-compiling
« on: December 11, 2010, 02:54:40 pm »
I think more function implementation should be done. Although I could be only one that thinks that. All of the drawing functions are essentially done (except surfaces). The rest of the resource functions just touch external loading and memory management (load and free). Then there is lots of other functions, but from drawing and so gameplay stand point everything could be ready for simple game creation and testing. As drawing is done by openGL I suspect it works for win, mac and linux out of the box. I would want to see the "Platform" dropdown box in LGM Enigma Settings to actually allow me choose between the three, but whatever. I would not be able to test it anyway as I have only windows right now.
Also, Wii support seems cool. Lots of possibilities there, thou I never got that damn thing. Maybe this could be a good enough reason to buy one.
Also, Wii support seems cool. Lots of possibilities there, thou I never got that damn thing. Maybe this could be a good enough reason to buy one.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »