SGX HuC lib question

[tonma]

Hi, I'm a new french dev on pc-engine.

I've just made some test with HUC and in asm like that (sprite and scroll) :

Now I wish to test the sgx. And I have found an old post here with sgx lib : https://www.pcengine-fx.com/forums/index.php?topic=7805.msg131620#msg131620 but didn't find the samples. www.pcedev.net/huc/SGX_AC_LIB/sample.zip

I was able to compile an example and show the layer of the SuperGrafx. But I don't know how to choose the layer. Does anyone know how to write tile/sprites on sgx vdc and at the same time on pce vdc ?

Maybe we need to use the pce vdc like usual, but how can we choose to update satb of the sgx and the pce ?

Thanks.

[NecroPhile]

Howdy, Hero.  I'm too dumb to help with programming anything more sophisticated than the clock on a VCR, yet I'm not too dumb to say welcome aboard! 

[elmer]

Welcome to the forum, it's always good to see another developer here. 

Now I wish to test the sgx. And I have found an old post here with sgx lib :
https://www.pcengine-fx.com/forums/index.php?topic=7805.0

It looks like that was one of Bonknuts's posts here when he was using the name "Tom".

I'm sure that he'll post something when he sees your question.

I was able to compile an example and show the layer of the SuperGrafx. But I don't know how to choose the layer. Does anyone know how to write tile/sprites on sgx vdc and at the same time on pce vdc ?

Have you seen Charles MacDonald's document on the SuperGrafx?

http://cgfm2.emuviews.com/txt/sgxtech.txt

That should give you all the information that you need if you're comfortable with a bit of assembly language.

Here's his document on the PCE if you haven't already seen it.

http://cgfm2.emuviews.com/txt/pcetech.txt

Good luck with your experiments!

[Bardoly]

Howdy, Hero.  I'm too dumb to help with programming anything more sophisticated than the clock on a VCR, yet I'm not too dumb to say welcome aboard! 

Agreed!  Welcome to Pcenginefx!

[TurboXray]

So do you have the SGX lib version 1.2? If not, I can upload it.

 I warn you ahead of time that HuC's map routines as well as other functionality is very slow. It's very generalized and it needs support (asm) to get around these issues. All the SGX stuff that mirrors the normal map and sprite HuC routines, are going to be just as slow. I simply copied the code and added VDC 2 port offsets. Using this lib is only going to compound any issues HuC already has, because now you are dealing with two VDCs. I just want that to be clear.

 Also, if you have the lib - you should have this: http://pcedev.net/sgx/sgx_lib.html

[tonma]

Thanks to all.

I think I have the last version, 1.2

Thanks about the slow warning. If I see lot of downrate, I'll change subroutines to asm.

[tonma]

Merry Christmas. 

Just to clarify for the slowness. Is it  the compilation with HUC or macros that are not optimized.
Or maybe the two ...

If it's the macros, I can begin to optimize them. But if this is the HUC compilation, I can just call the macro in asm.

[TurboXray]

Just to clarify for the slowness. Is it  the compilation with HUC or macros that are not optimized.
Or maybe the two ...

It's honestly not the macros. It goes much deeper than that. Part of it is code generation (pointer, array, and far data access) and part of it is higher level design issues on this style of processor.

Part of it is HuC and how it handles pointers and array access, as well as binary shifts - more so than your standard C output to asm (which tends to be slower). The other part is the actual libs (sprites, tilemaps, etc). They're written to be general and flexible, but they are slow by design (compared to commercial games where almost every game uses its own map routines). And then lastly, you're now support two VDCs.

 If you want to get back speed, write your town tilemap routines in asm and optimize accordingly. Write your own sprite routines as well. You'll need to write new routines to access array data (even near array data is treated as far data, which is very slow). Same for shifts. Use global variables where ever you can because private vars are slow. I have another lib that allows full screen hsync effects; Y and X line scroll, BG color #0 change, sprite/bg layer on/off, etc. It's fairly quick, and interfaces like a display list to the user side. But since HuC is horrendously slow with array access, you could spend almost a whole frame's worth of cycles with simply updating each entry.

 It's just that HuC isn't built for speed. It's needs asm support to prop it up just for PCE stuffs. Adding an extra VDC just compounds that issue. You also don't have access to the additional SGX 24k of ram with HuC either. And you end up writing a lot of assembly to fix these issues.

 This is why I don't post links or do anymore support lib stuff with HuC anymore. It's a losing battle. Writing new routines to support a specific project is one thing, but writing a generalized lib for anyone to use - is not optimal. And the people that use it, (Ark, Rov, touko), already have it figured out with their specific fixes.

 It comes down to the philosophy of 65x coding, which huc6280 is a branch of; every change or design usually requires re-optimization. The 65x is fast, but it isn't a strong general purpose processor like the 68k for which very little optimization needs to be applied for good results or changes to code. If you understand this at the ISA level, then you can begin to see why something as generalized as graphic libraries lose speed for what they gain in flexibility. And in HuC, writing new libs means writing in ASM. And if you can write in ASM, why do you even need HuC? I struggled to find a solution to this dilemma for a while, until I finally gave up. It's not just HuC, or its libraries, but this higher level concept. Other 65x machines, with better compilers like CC65, coders run into the same issues eventually. And ASM is the fix, or you limit the scope and capability of your project.

If it's the macros, I can begin to optimize them. But if this is the HUC compilation, I can just call the macro in asm.

If you are experienced with assembly, and the 65x ISA, then you could begin to add or replace support for HuC for your specific project. The first thing I would start with is point/array/far_data access. HuC has pragma fastcall function support, which allows you force argument passing via ZP or registers, instead of the internal slow stack. It allows you to use functions in asm that called in C like normal C directives and such. So instead of x=array[index]; , you could write something like x=NearDataArray(array,index);. I.e. something that sits in fixed ram bank. Pragma fastcall also allows argument overloading, so one function (depending on the number of arguments) can be used in different ways. I could also do NearDataArray(array,index,x); so the value of X is written into the array instead of vice versa. It'd be wise do to the same for shifts as well.

 I would also write all sprite handling and map handling in asm, from scratch. Once you get to know the PCE graphic hardware, you begin to realize sprite and map routines don't need to be restricted to vblank - which can speed things up if done right. The VDC interrupt service is also terribly slow in HuC,  not to mention limited in capability. I would completely remove/replace it.

 But in my opinion, that's quite a bit of down time learning the internals of HuC and how to interface asm stuff with it, and you still have to deal with the forced mapping layout of how HuC manages banks and pages.

 I don't want to discourage you, but you should know what you're getting into.

[tonma]

Thanks. And you don't discourage me. 

It's a great explanation. I already begin to write my sprite asm routines but I was hoping to save time by using some easy parts of huc. For example loading datas, etc ...

It will be a long and hard road but a great joy when the game will be 100% finished. I need to find time to work on.

[Sunray]

I use uli's updated version of HuC (https://github.com/uli/huc) which comes with some SuperGrafx support as well. Arrays are no longer far ptr accesses, you can use local variables etc. I'm working on my first PC Engine homebrew game at the moment and it's a breeze to develop using HuC. The only code that required assembly was the sound code (dda streaming). Having the game code in C is a must for me since I plan on porting the game to Amiga and DOS later.

Obviously there are some quirks that required me to recompile the compiler and modify the HuC library, but those are simple changes. Another quirk is that it is easy to write illegal C code that still compiles an runs but with undefined behavior, I solved that by cross-compiling the game code on PC with static analysis.

[tonma]

Hi, That's a good alternative. And making a game in C would be great. I think you have a good speed and no slowdown like the old huc.

I don't have yet a real pce to test, what emulator do you use to have the same speed than real hardware.

Will you make amiga game for the amiga 500, I don't know with can use C for that. But it's a good news. What software do you use ?

[TurboXray]

I use uli's updated version of HuC (https://github.com/uli/huc) which comes with some SuperGrafx support as well. Arrays are no longer far ptr accesses, you can use local variables etc. I'm working on my first PC Engine homebrew game at the moment and it's a breeze to develop using HuC. The only code that required assembly was the sound code (dda streaming). Having the game code in C is a must for me since I plan on porting the game to Amiga and DOS later.

Nice in that they fixed that glaring issue of treating fixed ram arrays as far data. Local variables used an internal stack (with indexing), which made them slow. How did this solve this? Especially for nesting functions? ZP+indexing address mode?

Obviously there are some quirks that required me to recompile the compiler and modify the HuC library, but those are simple changes. Another quirk is that it is easy to write illegal C code that still compiles an runs but with undefined behavior, I solved that by cross-compiling the game code on PC with static analysis.

What made you choose HuC over CC65? The existing library support?

[Sunray]

Nice in that they fixed that glaring issue of treating fixed ram arrays as far data. Local variables used an internal stack (with indexing), which made them slow. How did this solve this? Especially for nesting functions? ZP+indexing address mode?

You simply can't have nested function calls (this is a compiler switch). This is not a problem for me.

What made you choose HuC over CC65? The existing library support?

I wasn't aware of the CC65 until just recently. I probably not bother with it at this stage.KMN