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 »
2011
Proposals / Re: Tiering vs Components
« on: May 13, 2010, 09:08:32 am »
"They may be readable on their own, but less, more focused code is always more readable than more, unfocused code."
You'd best define focused if you're going to assert that yours is more so.
"Your code would be much longer, so you just omitted most of it and basically pretended the entire system. It's no wonder it's more readable here."
Is this your argument? My code is redundant, making it very simple for our zip-like memories to generalize them without having to examine them constantly. And considering tiers are more efficient nonetheless, I don't see how this is a problem.
"yours is coming from a long-standing plan. You've thought about the dependencies more, you can reorganize the components if you feel like."
And after all this thought, I say tiers are the way to go; you disagree. That implies you still feel you know better. How did that help your argument?
"you can reorganize the components if you feel like. Put coordinates in the collision component and pass it the other way."
I could do the same thing with tiers; it'd be a huge pain in the ass and it'd be counter-intuitive. Instance_nearest doesn't need the collision system or the sprite system; it just needs X and Y. Yes, you showed how to resolve those dependencies; they're easier with tiers, too, as you've agreed.
You'd best define focused if you're going to assert that yours is more so.
"Your code would be much longer, so you just omitted most of it and basically pretended the entire system. It's no wonder it's more readable here."
Is this your argument? My code is redundant, making it very simple for our zip-like memories to generalize them without having to examine them constantly. And considering tiers are more efficient nonetheless, I don't see how this is a problem.
"yours is coming from a long-standing plan. You've thought about the dependencies more, you can reorganize the components if you feel like."
And after all this thought, I say tiers are the way to go; you disagree. That implies you still feel you know better. How did that help your argument?
"you can reorganize the components if you feel like. Put coordinates in the collision component and pass it the other way."
I could do the same thing with tiers; it'd be a huge pain in the ass and it'd be counter-intuitive. Instance_nearest doesn't need the collision system or the sprite system; it just needs X and Y. Yes, you showed how to resolve those dependencies; they're easier with tiers, too, as you've agreed.
2012
Announcements / Re: Fixed those Makefiles
« on: May 13, 2010, 08:21:08 am »
kkg:
I did so in R3 where the only compiler we'd be using was the native GCC, but accounting for the Wii, I realized we would need makefiles at some point. I still didn't want to, so I considered the full set of benefits and flaws that would come with it;
Flaws:
- Labor. Oooh, labor.
Benefits:
- Any system under Platforms/ or Graphics_Systems/ could be compiled without ENIGMA even knowing they exist.
- - - This means that more systems could be added without any further hard-coding in the compiler.
- Make would enable compilation for more fragile systems, such as the Wii, which always use makefiles to get the job done right.
- Make would ultimately handle dependency resolution for me, compiling only what needed to be (as it does now).
At that point, it was clear that whatever work it took to learn make and write makefiles, even for newer systems down the road, it'd be worth it.
So I went the extra mile and wrote a shell script to write makefiles for me/other developers.
Also, it should correctly locate Make on Windows now, if anyone would bother to test 218.
I did so in R3 where the only compiler we'd be using was the native GCC, but accounting for the Wii, I realized we would need makefiles at some point. I still didn't want to, so I considered the full set of benefits and flaws that would come with it;
Flaws:
- Labor. Oooh, labor.
Benefits:
- Any system under Platforms/ or Graphics_Systems/ could be compiled without ENIGMA even knowing they exist.
- - - This means that more systems could be added without any further hard-coding in the compiler.
- Make would enable compilation for more fragile systems, such as the Wii, which always use makefiles to get the job done right.
- Make would ultimately handle dependency resolution for me, compiling only what needed to be (as it does now).
At that point, it was clear that whatever work it took to learn make and write makefiles, even for newer systems down the road, it'd be worth it.
So I went the extra mile and wrote a shell script to write makefiles for me/other developers.
Also, it should correctly locate Make on Windows now, if anyone would bother to test 218.
2013
Proposals / Re: Tiering vs Components
« on: May 13, 2010, 08:14:10 am »
Last I checked, cout << 's are usually pretty readable. Even when called debug_print.
I included a tier below. The others look identical, save the names. Somewhat of a nice part about tiers, really. My code would be much bigger, though; not without justification.
Your code is set up such that a separate component needs coded for a game that doesn't want to use sprites but still would like to use instance_nearest. So much for reusable behavior.
Oh sure, you can separate it into another component, but then an amazing thing happens; each component is dependent on another, kinda like my tiers. Astounding, really. It exhibits the same behavior.
I included a tier below. The others look identical, save the names. Somewhat of a nice part about tiers, really. My code would be much bigger, though; not without justification.
Your code is set up such that a separate component needs coded for a game that doesn't want to use sprites but still would like to use instance_nearest. So much for reusable behavior.
Oh sure, you can separate it into another component, but then an amazing thing happens; each component is dependent on another, kinda like my tiers. Astounding, really. It exhibits the same behavior.
2015
General ENIGMA / Re: ENIGMA's value
« on: May 12, 2010, 06:54:45 pm »
That may hold. I was referring to the fact that my incentive behind developing ENIGMA isn't to get paid for the hour, which will happen whether anything gets done or not; the people off whom that calculation is based put in what effort it takes to not get fired/stay on the boss's good side.
2016
Off-Topic / Re: FREE PORTAL
« on: May 12, 2010, 06:52:03 pm »
-Sigh-
It's "If at first you don't succeed, skydiving is not for you."
It's "If at first you don't succeed, skydiving is not for you."
2017
Proposals / Re: Tiering vs Components
« on: May 12, 2010, 06:48:04 pm »
Good.
Your edit doesn't follow; it's okay for your code to be unreadable if it's only unreadable in a sense that you don't care about?
Your edit doesn't follow; it's okay for your code to be unreadable if it's only unreadable in a sense that you don't care about?
2018
Proposals / Re: Tiering vs Components
« on: May 12, 2010, 02:36:31 pm »
Everyone who has remarked on the code in this thread has said that mine was the cleaner; I've heard nothing but how well-organized R4's system is from new developers.
2019
Proposals / Re: Tiering vs Components
« on: May 12, 2010, 12:52:50 pm »
Does that benefit the user? Because it sure as hell doesn't benefit me. And, as stated, any benefits it would offer the user can be emulated otherwise thanks to how ENIGMA is set up.
2020
General ENIGMA / Re: ENIGMA's value
« on: May 12, 2010, 10:06:32 am »
No, 90% of the code is mine. They're basing their calculations on the effort put out by people who get paid by the hour, not who work for beans.
2021
Off-Topic / Re: Music?
« on: May 12, 2010, 08:17:20 am »
"Basically, I can't listen to bad music and partly because of that, I often prefer silence."
I feel that way, too, and some people (especially those who know even less about astronomy than I do but refuse to omit it from their song) give me a knot in my stomach that makes me prefer not to have heard them speak. Others and their self-important idea of what should never have been called "singing" are better off just cutting the vocals. I do appreciate some lyrics, most often the ones I can't understand. So I tend to like songs in other languages and that are distorted or contain meaningless vocals.
I've told my friends, essentially, "Yes, I see you've found another song containing a guitar and someone raving about something in song. DO. NOT. WANT."
I feel that way, too, and some people (especially those who know even less about astronomy than I do but refuse to omit it from their song) give me a knot in my stomach that makes me prefer not to have heard them speak. Others and their self-important idea of what should never have been called "singing" are better off just cutting the vocals. I do appreciate some lyrics, most often the ones I can't understand. So I tend to like songs in other languages and that are distorted or contain meaningless vocals.
I've told my friends, essentially, "Yes, I see you've found another song containing a guitar and someone raving about something in song. DO. NOT. WANT."
2022
Proposals / Re: Tiering vs Components
« on: May 12, 2010, 08:11:43 am »
"You've split the parser, but you haven't split the debug code, which is somehow different and should stay in the same file."
No, it would operate the same way. There would be one declaration from the split files in the main file, and a function call in concerned functions.
"Classes, and thus the ways you can use them, are a feature of C++, so splitting debug code out would be relying on a feature of the language."
On one too many features of the language. I could put it all in a namespace, too. Doesn't really mean I'm going to.
"Components make things more readable"
For you
"and separate different purposes better,"
In your opinion
"which has somewhat more weight than putting debug code with what it's debugging with most programmers."
Have a poll? Hell, if I didn't print debug information inline, I'd double my line count trying to separate it. The actual debug code would be lost in all the hackish attempts to get at all the information I could have had immediately otherwise.
"Polymorphism is a nice feature that makes code more readable, putting debug code in a separate file does the same thing."
"Makes code more readable"? I'll give you, "can make code more readable." Regardless, the debug code can and sometimes will be in a separate file, but there will still be a call to it in the main file. The call will be about a line long, maybe two if I include a comment or three if it requires a real lot of parameters. You can't really debug a loop without having some inline debug code for it. Unless you want to have your debug code make a separate iteration, which I'm sure you'd have no problem with.
No, it would operate the same way. There would be one declaration from the split files in the main file, and a function call in concerned functions.
"Classes, and thus the ways you can use them, are a feature of C++, so splitting debug code out would be relying on a feature of the language."
On one too many features of the language. I could put it all in a namespace, too. Doesn't really mean I'm going to.
"Components make things more readable"
For you
"and separate different purposes better,"
In your opinion
"which has somewhat more weight than putting debug code with what it's debugging with most programmers."
Have a poll? Hell, if I didn't print debug information inline, I'd double my line count trying to separate it. The actual debug code would be lost in all the hackish attempts to get at all the information I could have had immediately otherwise.
"Polymorphism is a nice feature that makes code more readable, putting debug code in a separate file does the same thing."
"Makes code more readable"? I'll give you, "can make code more readable." Regardless, the debug code can and sometimes will be in a separate file, but there will still be a call to it in the main file. The call will be about a line long, maybe two if I include a comment or three if it requires a real lot of parameters. You can't really debug a loop without having some inline debug code for it. Unless you want to have your debug code make a separate iteration, which I'm sure you'd have no problem with.
2023
Announcements / Fixed those Makefiles
« on: May 12, 2010, 08:00:05 am »
Good news everyone. I got the makefiles not to recompile all the time. I've not yet committed my changes though; be patient. I want to make sure all the changes I've made to the syntax checker and parser hold up during some field testing, and there's some code that needs moved around because it's being called too often.
Anyway, I'm not sure I can enumerate all the changes between my next revision (expect it tonight) and my last; that's why we have Diff.
The IRC has relieved me of the things I usually keep in a list to say when I make a newspost, especially with freezway asking how makefiles are coming every twenty minutes. Freezway, the makefiles work, but you can't have them. So there.
I may as well share concerns as well as success. I decided to use makefiles, despite them being an ancient art that's a huge pain to get working, because I wanted individual systems to be responsible for their own rules of building. This would be especially helpful, I thought, when we did the Wii port, which is necessarily Make-based. Problem is, I'm not sure what changes would need made to the makefile (particularly the ones under SHELL/ and SHELL/Universal_System/) to enable the modified Make to compile it correctly. I will need to thoroughly inspect the Wii-written makefiles for things that need set.
The most glaringly obvious of these is that $(DEVKITPPC) needs set, and that it includes a file called wii_rules from that directory. This leaves a number of questions that I can't yet answer with certainty. Namely, do I want to make it so that every system relies on a file called $(COMPILER_DATA)/$(PLATFORMNAME)_rules? Do I want to just include makefiles/makefile.$(PLATFORMNAME)?
It seems the latter would be the simplest as well as the most easily extended since as many files can be dumped into that folder as the OS allows, and the makefile will include any of them LGM/ENIGMA request by name or fragment of name (wii, pc, etc). It is what I will likely be going with unless someone has a better idea.
That leaves one additional problem that needs dealt with for a number of reasons. How do we incorporate multiple compilers? Currently, ENIGMA frantically searches for c++ and g++ at load time. If it doesn't find them, it errors to Ism, who asks the user. Either way, it leaves knowing where gcc and make/mingw32-make are located. That location name can be made into a map, certainly. But, where do we store compiler information? A new folder, ENIGMAsystem/compilers/? A new text file, ENIGMAsystem/compilers? The former would be more desirable so that, should compilers be pluginized (and this is thinking way ahead), plugins aren't fighting for permissions and last word in one text file, and aren't iterating it on and off for their input. It would just rely--as the entire remainder of the system would, really--on no two compilers sharing a name.
Perhaps all that belongs in Proposals anyway, I guess I just needed something to put in this newspost. Maybe I'll post it there later.
Anyway, real work to do now.
Cheers.
Anyway, I'm not sure I can enumerate all the changes between my next revision (expect it tonight) and my last; that's why we have Diff.
The IRC has relieved me of the things I usually keep in a list to say when I make a newspost, especially with freezway asking how makefiles are coming every twenty minutes. Freezway, the makefiles work, but you can't have them. So there.
I may as well share concerns as well as success. I decided to use makefiles, despite them being an ancient art that's a huge pain to get working, because I wanted individual systems to be responsible for their own rules of building. This would be especially helpful, I thought, when we did the Wii port, which is necessarily Make-based. Problem is, I'm not sure what changes would need made to the makefile (particularly the ones under SHELL/ and SHELL/Universal_System/) to enable the modified Make to compile it correctly. I will need to thoroughly inspect the Wii-written makefiles for things that need set.
The most glaringly obvious of these is that $(DEVKITPPC) needs set, and that it includes a file called wii_rules from that directory. This leaves a number of questions that I can't yet answer with certainty. Namely, do I want to make it so that every system relies on a file called $(COMPILER_DATA)/$(PLATFORMNAME)_rules? Do I want to just include makefiles/makefile.$(PLATFORMNAME)?
It seems the latter would be the simplest as well as the most easily extended since as many files can be dumped into that folder as the OS allows, and the makefile will include any of them LGM/ENIGMA request by name or fragment of name (wii, pc, etc). It is what I will likely be going with unless someone has a better idea.
That leaves one additional problem that needs dealt with for a number of reasons. How do we incorporate multiple compilers? Currently, ENIGMA frantically searches for c++ and g++ at load time. If it doesn't find them, it errors to Ism, who asks the user. Either way, it leaves knowing where gcc and make/mingw32-make are located. That location name can be made into a map, certainly. But, where do we store compiler information? A new folder, ENIGMAsystem/compilers/? A new text file, ENIGMAsystem/compilers? The former would be more desirable so that, should compilers be pluginized (and this is thinking way ahead), plugins aren't fighting for permissions and last word in one text file, and aren't iterating it on and off for their input. It would just rely--as the entire remainder of the system would, really--on no two compilers sharing a name.
Perhaps all that belongs in Proposals anyway, I guess I just needed something to put in this newspost. Maybe I'll post it there later.
Anyway, real work to do now.
Cheers.
2024
Proposals / Re: Tiering vs Components
« on: May 11, 2010, 08:17:15 pm »
"What's wrong with splitting a shared behavior into a different file, especially when it's for debugging purposes only?"
Nothing; I've split pieces of a single parser into separate files. What's wrong with relying on the features of a language to handle that?
"Just because you can handle extra #if blocks and debug lines littering your code doesn't mean it's ideal."
I believe the same about components for everything.
"I'm sure you could handle writing Enigma in C, why use C++?
Because C++ implements polymorphism which I would otherwise have to handle myself, which would take a phenomenal amount of effort.
"But it is a suggestion as to why you have so few developers."
As if we needed a reason for that. Ism's on her own now, too. Where did she go wrong? Hell, a lot of open source projects are. That's a pretty trashy reason.
Nothing; I've split pieces of a single parser into separate files. What's wrong with relying on the features of a language to handle that?
"Just because you can handle extra #if blocks and debug lines littering your code doesn't mean it's ideal."
I believe the same about components for everything.
"I'm sure you could handle writing Enigma in C, why use C++?
Because C++ implements polymorphism which I would otherwise have to handle myself, which would take a phenomenal amount of effort.
"But it is a suggestion as to why you have so few developers."
As if we needed a reason for that. Ism's on her own now, too. Where did she go wrong? Hell, a lot of open source projects are. That's a pretty trashy reason.
2025
Proposals / Re: Tiering vs Components
« on: May 11, 2010, 07:53:46 pm »
"They're object specific and operate in the context of their owner."
Then they should be coded in the context of the owner, including the file.
"You could, for example, mute, make invisible, highlight or otherwise affect a specific object from within that object."
Like what visible = 0; does. Ingenious.
"In build mode, components would go along with or even make unnecessary your #if by handling build mode-specific behavior from within each object."
Yes, but the #if takes up less space and requires only the changing of a single flag. Besides, the option to include Build and Debug mode when compiling a game is not a feature that can be turned off, and is of the few things the system is absolutely designed around the idea of including an option for.
"Anyway- you don't have to use components. Tiers will just be another part of Enigma that makes me not want to contribute."
Your only contribution before you cared about how the rest of the system looked was too incomplete to use... Is that a veiled threat?
"You can organize files however you want, but mixing debug and normal code just makes things less readable and workable."
Most of us can learn to ignore a single line reading debug_call(), the rest should sleep before/instead of developing for a large project.
"Put them in a debug folder mirroring the main tree or something- debug code does not belong with release code, it's not for the same purpose."
Sure, it's not for the same purpose, but it should be designed to integrate with that purpose. As for the separate tree, that's fine, if a bit extreme--I was thinking a separate source--, but the declaration and call of the function is still being included in the main system.
"Sticking it in at compile time is a little better, but you don't do this everywhere and swapping a pointer is still much simpler than recompiling and inserting new blocks of code."
Better for someone who can't juggle the purpose of the code and a single-line debug call, certainly.
Then they should be coded in the context of the owner, including the file.
"You could, for example, mute, make invisible, highlight or otherwise affect a specific object from within that object."
Like what visible = 0; does. Ingenious.
"In build mode, components would go along with or even make unnecessary your #if by handling build mode-specific behavior from within each object."
Yes, but the #if takes up less space and requires only the changing of a single flag. Besides, the option to include Build and Debug mode when compiling a game is not a feature that can be turned off, and is of the few things the system is absolutely designed around the idea of including an option for.
"Anyway- you don't have to use components. Tiers will just be another part of Enigma that makes me not want to contribute."
Your only contribution before you cared about how the rest of the system looked was too incomplete to use... Is that a veiled threat?
"You can organize files however you want, but mixing debug and normal code just makes things less readable and workable."
Most of us can learn to ignore a single line reading debug_call(), the rest should sleep before/instead of developing for a large project.
"Put them in a debug folder mirroring the main tree or something- debug code does not belong with release code, it's not for the same purpose."
Sure, it's not for the same purpose, but it should be designed to integrate with that purpose. As for the separate tree, that's fine, if a bit extreme--I was thinking a separate source--, but the declaration and call of the function is still being included in the main system.
"Sticking it in at compile time is a little better, but you don't do this everywhere and swapping a pointer is still much simpler than recompiling and inserting new blocks of code."
Better for someone who can't juggle the purpose of the code and a single-line debug call, certainly.
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 »