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 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
751
General ENIGMA / Re: Shader Factory
« on: May 24, 2013, 02:29:02 pm »
If that shader factory can export Cg scripts, then I see every reason to make sure we can support its format in our shader API, when we get around to writing one.
752
General ENIGMA / Re: EGMJS (ENIGMA HTML5)
« on: May 24, 2013, 02:27:31 pm »
The new compiler is set up in a way that makes it cater to multiple languages. When TGMG and I are done with schoolwork, we will collaborate to get EGMJS working. In the meantime, I fear it's a crapshoot. Maybe Ism can help with some Java-side bugs.
753
General ENIGMA / Re: Innacurate Framerate Counter
« on: May 24, 2013, 02:25:19 pm »
I was being dramatic, forthevin. The scheduler doesn't care how long you ask it to sleep; if you're not using the CPU when you're given it, it's going to forget about you. But Sleep() cannot take a value less than one, meaning your game, by definition, cannot use Sleep() and have a framerate higher than (or even equal to) 1000.
754
General ENIGMA / Re: EGMJS (ENIGMA HTML5)
« on: May 24, 2013, 02:28:21 am »
Holy crap. Was that working with the latest LGM?
755
General ENIGMA / Re: Innacurate Framerate Counter
« on: May 24, 2013, 12:46:56 am »
Oh, listen to you.
You're as bad as polyfuck. Neither of you two fucking understand how an operating system works, so you blame (and try to compensate for) features of the OS you don't understand in the engine. Here's what's happening:
Exhibit A: User with IQ of 6
Quote
perhaps 73 step events per second and 30 locked draw eventsIn an engine without threading. Physics systems do that sometimes. With threading.
Quote
Quote
because ENIGMA may just decide your game does not need more than 53fpsBoo-hoo; ENIGMA won't let my game run faster than 53.
You're as bad as polyfuck. Neither of you two fucking understand how an operating system works, so you blame (and try to compensate for) features of the OS you don't understand in the engine. Here's what's happening:
Exhibit A: User with IQ of 6
- Exhibit A wants to test ENIGMA's POOOOOWAAAAAAAAAAAAAAAAAAAAAAAH
- Exhibit A creates a new game and sets the FPS to NINE THOUSAAAAAAAAAAAAAAAAAAND
- Exhibit A presses Run
- Compile takes a really long time because Exhibit A has never built any piece of the engine before
- While Exhibit A is looking for the firefox button in his 50-page start menu, compile finishes
- The empty game begins
- The event loop begins, and then terminates immediately because, oh yeah, IT'S FUCKING EMPTYYYYYYYYYYY
- The draw loop begins. It clears the screen to gray and exits, because, oh yeah, IT'S ALSO FUCKING EMPTYYYYYYYYY
- The necessary amount of time required to sleep is calculated. This value equates to 1000 / (NINE THOUSAAAAAAAAAAAAAAAAAAND) = 0 milliseconds
- The max of that time and 1 is taken to prevent Sleep() from aborting the game and/or crashing Windows, and Sleep() is invoked.
- Since 6 microseconds have passed, the scheduler sticks the process at the end of the wait queue and forgets about it for a few thousand years
- After the few thousand years (or about 17 milliseconds, if you aren't watching as an electron) pass, the scheduler remembers, OH SHIT
- The scheduler removes your game from the waiting queue and returns context to it
- This loop continues, resulting in a framerate of 53
- Why is my game running at 53 FPS? ENIGMA IS SO CRUEL
- I'm going to kill myself, but not before crying about how bad ENIGMA is on the internet
756
Proposals / Re: While we (as in forthevin) are moving shit
« on: May 23, 2013, 02:42:33 pm »
Is it just me, or is that snippet tag a bit ugly? Maybe I'll add a teletype tag in the near future.
757
Proposals / Re: While we (as in forthevin) are moving shit
« on: May 23, 2013, 02:41:22 pm »
By aliased, I assume you mean [snip]#define[/snip]'d? There is another way we have aliased function in the past, but it might not bode as well with [snip]-flto[/snip] when I finally get around to passing that flag. I believe we did it for [snip]make_color[/snip]; we just used [snip=edl]int (*const make_color)(unsigned char,unsigned char,unsigned char) = make_color_rgb;[/snip], which, as you know, copies the function pointer to a new variable. I'm not really a fan of this, as I believe it forces the compiler to make both functions use CALL, but I could be mistaken (especially if we add a [snip]const[/snip] in after that asterisk).
I am personally fine with macros, at very least for now.
I am personally fine with macros, at very least for now.
758
ALLCAPS BOARD / Re: Should we add a timeout option to account settings?
« on: May 23, 2013, 01:53:29 pm »759
Issues Help Desk / Re: file_find functions
« on: May 23, 2013, 01:41:50 pm »
That's fine. I've committed the fix now; you should be able to use those functions.
760
Issues Help Desk / Re: file_find functions
« on: May 23, 2013, 12:50:51 pm »
Unfortunately, I was unable to test the functions before committing them due to my current platform. Hang tight, I'll fix that.
761
Issues Help Desk / Re: file_find functions
« on: May 23, 2013, 08:51:11 am »
Assuming [snip]home[/snip] is a variant or string, you don't need to keep casting it to string(), but other than that, you are fine. The issue is that forthevin moved the header into the enigma_user namespace, but did not move the source (or, more likely, the implementation of that particular function was in another castle).
I'll fix that real quick; hang tight.
EDIT: Seems this has nothing to do with forthevin. The function just wasn't implemented.
EDIT2: I have implemented those functions and [snip=edl]get_environment_variable()[/snip], which I recommend you use in place of [snip=edl]getenv()[/snip]
I'll fix that real quick; hang tight.
EDIT: Seems this has nothing to do with forthevin. The function just wasn't implemented.
EDIT2: I have implemented those functions and [snip=edl]get_environment_variable()[/snip], which I recommend you use in place of [snip=edl]getenv()[/snip]
762
Issues Help Desk / Re: file_find functions
« on: May 22, 2013, 07:25:43 pm »
ENIGMA depends on file_find functions in the compiler, so they are almost certainly implemented in the engine. What platform aren't they working on?
763
Proposals / Re: While we (as in forthevin) are moving shit
« on: May 22, 2013, 01:45:00 pm »
My only bitch with macros is that the syntax checker will sound stupid. The code will read [snip=edl]irandom(1,2,3)[/snip] instead of [snip=edl]choose(1,2,3)[/snip], and the checker will bitch, "Too many arguments to function `random_integer': expected at most 2, provided 3". That might confuse the fuck out of people, or they might assume that ENIGMA is a mind-reading sentient. Either way, it's a little tacky.
764
Proposals / Re: While we (as in forthevin) are moving shit
« on: May 22, 2013, 07:58:34 am »
forthevin: You reading this? It seems you've begun migrating [snip]#define[/snip]'d functions to [snip]enigma_user[/snip] by rewriting them as regular functions that call the original. That's, in general, a good idea, but it breaks overloads. Would you be interested in a parser macro specifically designed to alias a function in ENIGMA's compiler? You'd call something like [snip]$ENIGMA_alias(random_integer, irandom)[/snip], and it would create a duplicate definition in the current scope. Just an idea.
Otherwise, we'll have to stick with macros for the time being. Or worse: alias all overloads. Not a fan of that idea.
I don't mind macros, because what we're avoiding is C++ definitions that conflict with user code, not user/ENIGMA code that conflicts with C++ definitions.
Otherwise, we'll have to stick with macros for the time being. Or worse: alias all overloads. Not a fan of that idea.
I don't mind macros, because what we're avoiding is C++ definitions that conflict with user code, not user/ENIGMA code that conflicts with C++ definitions.
765
General ENIGMA / Re: Definitions Modified
« on: May 20, 2013, 01:49:41 pm »
Couldn't have been. Only ENIGMA needs this feature, and ENIGMA has been using exclusively the JoshEdit branch for ages. The lack of resource highlighting might have been an issue, though.
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 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »