|
Post by elmer on Sept 1, 2022 23:13:25 GMT
Many thanks for looking into this elmer ! Any advice is greatly appreciated! The codes are in your inbox. OK, I've taken a look and it's not a bug in HuC, your code really is just using far too many procedures for HuC to handle! It's not good that the MapED and SprED libraries are using over 100 procedures themselves just to provide simple functionality, where often the MapED/SprED library function is smaller than the procedure trampoline used to call it ... that's not great design, but you could live with that because you *need* that library functionality. What's bringing the whole environment crashing down, is your code-design where you're doing everything as individual object-specific functions rather than coming up with a simple set of common functions that use data stored in arrays. Things like ZUK_STAR_STATE() / ZUK_STAR_FRAME() / ZUK_STAR_REV_STATE() / ZUK_STAR_REV_FRAME() / etc where you're just repeating the same code dozens or hundreds of times with only tiny changes in the data values ... that's what is generating dozens of banks of pointless code and the over 400 procedures (for a total of over 530) that are causing the compiler to choke. May I suggest that you either consider rethinking the design, or that you write the different sections as CD-ROM overlays so that you limit the code used for each section.
|
|
|
Post by 0x8bitdev on Sept 2, 2022 9:13:05 GMT
It's not good that the MapED and SprED libraries are using over 100 procedures themselves just to provide simple functionality, where often the MapED/SprED library function is smaller than the procedure trampoline used to call it ... that's not great design, but you could live with that because you *need* that library functionality. You brought up an interesting topic. I didn't even think about the number of procedures in the MPD/SPD libraries. I even wondered how many there are. That there are more than 100 is an exaggeration. It's about 100 in both libraries. I looked in the .lst file and counted: SPD: 31 (29 public functions) MPD(multidir map): tiles4x4: 58 with entities enabled +8 MPD(multidir map): blocks2x2: 60 with entities enabled +8 The libraries provide a fairly wide range of functionality, so it is impossible to significantly reduce the number of procedures without duplicating code. But supporting a library with a lot of duplicated code will lead to more bugs. The fact that the library function is smaller than the procedure trampoline used to call it is an exception, not a rule. There are not many such procedures. As a rule, that is a redirect to MagicKit routines.
|
|
|
Post by hyperfighting on Sept 2, 2022 12:49:27 GMT
elmer - I very much appreciate you taking the time to review my project! After I hyperventilated a little bit my game plan will be to attempt to eliminate all those STATE/FRAME functions that you pointed out. Based on what you said I'm thinking a const array for each actor that has the instructions I was storing in each of the STATE/FRAME. I will try this before I throw in the towel and go CD-ROM. I love the turbo chip format too much! CD-ROM would be pretty cool though...CD quality sound right away! Well thanks again! Without your help I would have been totally lost. I will get to work and let you know how it goes. Any suggestions are greatly appreciated I think I am on right track.
|
|
fabio
What's a PC Engine?
Posts: 2
|
Post by fabio on Sept 21, 2022 19:33:21 GMT
Hi guys. New to the forum. Asking a questions you must have already seen dozen of times : I'm just willing to start coding Pc Engine stuff using Huc. Already doing stuff on the Megadrive using SGDK. So i'm looking for as much ressources as possible, code samples, doc about the Huc library, and so on...
Thx guys.
|
|
lunoka
Gun-headed
Diving into retrodev
Posts: 55
Homebrew skills: art, music
Fave PCE Shooter: Burning angels
Fave PCE Platformer: Ninja Spirit
Fave PCE Game Overall: Valis 3
Fave PCE RPG: Neutopia
|
Post by lunoka on Sept 22, 2022 12:32:34 GMT
|
|
|
Post by 0x8bitdev on Mar 18, 2023 10:23:19 GMT
It would be convenient to add to the end of the procedure list in .lst file information about their total number, taking into account 'procgroups'. Something like: TOTAL PROCEDURES: XXX of YYY
or just TOTAL PROCEDURES: XXX
When you have dozens of procedures and 'procgroups' in the list, it's impossible to know their number based on the list info, because 'procgroup' hides its procedures. It will be easier to count them in a project, especially if someone exceeds the limit. Attached is a simple test program with a couple of 'procgroups' to save some time. procgroups_test.7z (366 B)
|
|
|
Post by hyperfighting on Mar 18, 2023 19:34:23 GMT
0x8bitdev - Would you mind elaborating on the use case for ".procgroup's" ? This is my first exposure to them. This will sound elementary but here goes...my current perception. -"Procedure" is the asm equivalent to a C function -"Procedure Group" is a list of procedures. Is the intention to call these procedures in sequence? If so why not just call them in the code one by one? Well the answer must be to have a clean single line in the code that calls several procedures when it is referenced. Please correct me if I'm far off... Sorry for commenting this peaked my curiosity - Not to take away from the initial question Posted by 0x8bitdev
|
|
|
Post by 0x8bitdev on Mar 19, 2023 10:36:45 GMT
0x8bitdev - Would you mind elaborating on the use case for ".procgroup's" ? This is my first exposure to them. 'Procgroups' are used in PCEAS to guarantee that associated procedures (or data, you can use LUTs) will be placed in the same memory bank. You can use 'procgroups' depending on the context you have. For example, you have a set of performance-critical procedures that you call somewhere in one place in your program. After compilation that procedures can be placed in different memory banks. And you want to avoid memory banks switching when you call them. To achieve that you can unite them in one 'procgroup' that will be placed 100% in one memory bank. Or you may have 2 public procedures that use the same routine. There are two ways to make your program work properly: 1. You can make all of them as procedures (.proc/.endp). As the result you will have 3 procedures. And it doesn't matter which memory banks they will use. 2. Or you can combine them into 'procgroup'. As the result you will have 2 public procedures and the correct call of the common routine. It always be in the same memory bank and you can call it using simple jsr. etc... The main thing is that 'procgroup' does not exceed the size of memory bank - 8KB. ...and without fanaticism!...
|
|
|
Post by hyperfighting on Mar 19, 2023 14:14:33 GMT
0x8bitdev - This is great info! Thanks for elaborating! Silly me thinking it was just a quick way of executing several functions! The Memory Bank info is gold and the technique to keep your routines to a minimum is awesome!
|
|