Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 8, 2015 19:04:04 GMT -5
I agree with moon. I've written several successful games in BEX (not all were released, unfortunately), and BEX is as powerful as you make it. It does have its flaws and bugs, but they aren't impossible to work around. Besides, there's a few people here that are very knowledgeable and are more than willing to help you if you do get stuck (providing there's effort being shown to understand the platform and language and not just "oh, how do I do this" every 30 minutes )
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 12, 2015 13:04:39 GMT -5
I wonder if this project could be stripped down to a working example of using Echo. I was never quite able to understand the instructions on getting it to work with BEX.
|
|
|
Post by lunchbox on Jan 14, 2015 11:00:51 GMT -5
"oh, how do I do this" lol ^^
At the end of the day there is no better way than to take it apart yourself and try to get it working. If you still dont understand the example or code in a language such as basic with the addition of a few included asm subroutines (called) then maybe taking a few steps back and relearning a few things or starting from step one is a good idea.
|
|
|
Post by Tamkis on Jan 17, 2015 23:05:08 GMT -5
( Wow, somebody actually read my blog! Now if only I could get some regular followers for motivation instead of being an anonymous loner coder blogging and coding in a vacuum ...) I did not mean any offense by to the BEX community with that SGDK vs. BEX comment. Both have their pros and cons, though, at least for me, I have had trouble in the past with making BEX code too structured with things crashing for no reason. I asked previously with help with fixing the unknown lockup during runtime with the StickMove subroutine, but no one could find the problem, not even myself. Previously, that subroutine was working perfectly, then one day after adding code elsewhere in the program, the "branch out of range" compilation error began to occur, and the program began to lockup for no reason in StickMove. It's a compiler bug I believe. I don't have any good backups of the development to see what I added that started to cause problems either. Also, with the fact that the program was successfully compiling despite a "branch out of range" error due to large code size was a red flag to me that further development might implode once the code got larger; the compiled binary was already 1.4MB IIRC. Also having to recreate the QB64 SpriteLibrary (which uses dynamic structs and other complex things) in BEX (static) was over my head. I wonder if this project could be stripped down to a working example of using Echo. I was never quite able to understand the instructions on getting it to work with BEX. You should be able to strip it down. Do note however I modified paths so that I have separate folders for FM, DAC (used in songs), PCM (DAC used as sound effects), and Music (.esf files). Sorry about cancelling it. Once the game development in SGDK is close to what it was prior to cancellation, I'll make a new thread in the "Development section". It ain't over yet! [/b][/b]
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 18, 2015 5:04:09 GMT -5
Asking someone to go through your code is an unrealistic expectation. Afaik, you didn't isolate the code in question so why would you expect someone else to?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 18, 2015 9:05:54 GMT -5
I did not mean any offense by to the BEX community with that SGDK vs. BEX comment. Both have their pros and cons, though, at least for me, I have had trouble in the past with making BEX code too structured with things crashing for no reason. No worries. It's entirely possible that your coding style matches C better than BASIC. I asked previously with help with fixing the unknown lockup during runtime with the StickMove subroutine, but no one could find the problem, not even myself. I actually helped you once ( by going through the entire source code ) when you couldn't get it to compile anymore .. Your post - devster.proboards.com/post/9874/threadMy response - devster.proboards.com/post/9875/thread.. but i don't think you can't expect people to do that for you multiple times. In fact ( like elusive said ) .. i don't think it's realistic to expect that at all with a project of such scope and ( to be honest ) sub-par code quality* *Which is perfectly normal, my first BEX projects were a mess as well. Also having to recreate the QB64 SpriteLibrary (which uses dynamic structs and other complex things) in BEX (static) was over my head. I never understood why you wanted / tried to do this in the first place.
|
|
|
Post by Tamkis on Jul 17, 2015 0:10:50 GMT -5
Ported some of the BEX code to SGDK in a refactor/redo attempt. Although it does make asset management somewhat more streamlined, not everything is greener on the other side . But will continue my attempt gendev.spritesmind.net/forum/viewtopic.php?t=2051
|
|