_25_11_2024_15_40_33.jpg)
_25_11_2024_15_40_55.jpg)
_25_11_2024_15_43_24.jpg)
|
Socoder -> Off Topic -> Descriptive Code |
|
| Wed, 10 Apr 2019, 10:26 | |
spinal
|
Am I just too set in my ways? a forum member over at the Pokitto forum ask if he could adjust my code a little... Linkage ...as I predicted, he spent a bunch of time and effort turning my nice byte arrays into something I can't read very well, nor see the point of. Am I just too set in my ways, is this way of data storage really better? even for something as simple as a stream of audio data?
-=-=- Check out my excellent homepage! 
|
| Wed, 10 Apr 2019, 10:26 | |
|
spinal
|
I'm really asking for a 3rd opinion here, as his and mine are exact opposite.
-=-=- Check out my excellent homepage!
|
| Wed, 10 Apr 2019, 10:37 | |
Jayenkai
|
He's working on the assumption that you're "coding" the music. If it were me making the music, I'd write a quick Blitz tool, and export the data, then cram it into an array like you have. I don't need to tweak the music code, I just have to tweak the tune in the Blitz proggy, then re-export it. But then, I grew up typing things like Symbol 52,26,2,162,48,255,8,3, creating little sprites in my head as I went, without worrying about it. I think the era/computing style that we grew up in is probably the deciding factor, here.. -=-=- ''Load, Next List!''
|
| Wed, 10 Apr 2019, 10:50 | |
spinal
|
So I'm old then 
|
| Wed, 10 Apr 2019, 11:12 | |
|
Jayenkai
|
I often look at things like XML, and think "gawd, what a waste of space!!", knowing that the mBs of data can be compressed to a few kB if they stripped away all of the descriptive stuff. I still worry about "bloat", even when, really, I shouldn't. But .. meh, whatever. At the end of the day, the end result should be all that matters, and therein lies another reason why you won't be seeing a "Jay Coding Tips" book any time soon!! -=-=- ''Load, Next List!''
|
| Wed, 10 Apr 2019, 12:00 | |
|
Krakatomato |
What I find frustrating these days is that people are so keen to re-engineer stuff so that it's "better". Better for what? Better for who? I've worked (and still do) as an Enterprise Architect for a number of very large companies and I can tell you now that they spend oodles of money on refactoring, re-engineering, re-architecting, etc. All the new technologies. All the things. And then they moan that it's unsupportable, complex, slow, "OMG - HOW MUCH IS THIS COSTING!". Frustrating - but I have to go with the flow or they think it's no good. /me SIGHS! Anyway, I think your implementation is sound. It's compact, concise and readable. You do not need to expand it into something unnecessary like that - unless there's a solid use-case that deems it so. Good lad Spinal - keep up the good work mate. //Andy
|
| Wed, 10 Apr 2019, 12:54 | |
cyangames
|
I'm of the opinion that if it works, it works.
-=-=- Web / Game Dev, occasionally finishes off coding games also! |
| Thu, 11 Apr 2019, 15:06 | |
therevillsgames
|
K.I.S.S
|
| Thu, 11 Apr 2019, 16:25 | |
rockford
|
When I code something it's to get the job done. It's never about making the code look great, making the code as short or fast as possible, or anything other than making it run, as bug-free as possible to my specifications. If it does what I want, exactly how I want it done, then jobs a good'un. I may well tweak the code in the future to improve it, but initially the task is to get it working. Because that's ALL that matters. |
| Mon, 15 Apr 2019, 05:30 | |
|
cyangames
|
Had a look through the code on the link, I tend to go for Spinals style normally, it just makes more sense in my head visually. I use a similar format for my NES and Gameboy music engines written in ASM and C respectively. -=-=- Web / Game Dev, occasionally finishes off coding games also! |
| Mon, 15 Apr 2019, 06:55 | |
|
spinal
|
Yeah, I'm keeping my code, with the exception of reversing the endien-ness of the non-audio data so that it can be read quicker.
-=-=- Check out my excellent homepage!
|
|
|
| |||
|
| ||||