|
Post by monstersgoboom on Mar 10, 2020 16:53:57 GMT
There's a few forks floating around. I forked jbrandwood/huc and added my changes to include .BMP file format ( the map editor I use only supports .BMP ! )
added .DD keyword to assembler for double word defs in asm EG.
fixed_number: .dd $00000100
fixed_number: .db $00,$01,$00,$00
for working with math32 routines available already.
added support for load_vram2. looks like this was intended to be there but wasn't
load_vram2(VRAM_ADDR,DATA_PTR,BANK,WORD_COUNT);
I'm curious if that's the most current ?
cheers
|
|
|
Post by turboxray on Mar 11, 2020 1:57:07 GMT
Bmp was added? Finally hahah
|
|
|
Post by monstersgoboom on Mar 11, 2020 2:16:09 GMT
|
|
|
Post by DarkKobold on Mar 11, 2020 16:45:05 GMT
Elmer fixed some palette stuff, but that broke some of the font routines. He'd fixed that as well, but I don't think a public build has been released. However, it sounds like you are capable of building that yourself.
|
|
|
Post by elmer on Mar 14, 2020 2:43:11 GMT
There's a few forks floating around. I forked jbrandwood/huc and added my changes to include .BMP file format ( the map editor I use only supports .BMP ! ) I'm curious if that's the most current ? As far as I can tell, my fork is the only "active" fork at the moment. Artemio still makes rare changes to his fork, and I just updated mine yesterday with his final change from last year. It's absolutely great to see that you're willing to dig into the code and make updates/changes yourself, we've sadly-lacked programmers who are willing to take things into their own hands and help to improve HuC. Having said which ... I had no idea that anyone needed .BMP support in PCEAS, it's never been mentioned before. I already have .BMP reading/writing code from long, long ago, which I've been updating to work in a new standalone grahpics converter program to add to the HuC tools. As such, I'd kinda rather not add .BMP format support to my fork of PCEAS at this point, unless someone can make a good argument for why it should be there. IMHO, for the long-term future of HuC, and assembly-language development on the PCE in general, we'd be better off having a separate open-source graphics converter added to the HuC distribution rather than keep on adding graphics converters into PCEAS itself. Everyone please feel free to disagree and share your own opinions ...
|
|
|
Post by turboxray on Mar 14, 2020 3:06:41 GMT
I liked the BMP format because you don't need a library to handle the image format. It's pretty simple to write a header check and body decoder for it, so that's why I've always used it. I'm a fan haha
|
|
|
Post by dshadoff on Mar 14, 2020 4:18:08 GMT
I also like BMP, but only if the various forms of it are supported (mono is very rarely supported...).
I’d be happy to get it converted to a PCE binary to include, instead of directly including and converting inline, as you suggest.
|
|
|
Post by DarkKobold on Mar 14, 2020 20:55:54 GMT
As such, I'd kinda rather not add .BMP format support to my fork of PCEAS at this point, unless someone can make a good argument for why it should be there. IMHO, for the long-term future of HuC, and assembly-language development on the PCE in general, we'd be better off having a separate open-source graphics converter added to the HuC distribution rather than keep on adding graphics converters into PCEAS itself. Everyone please feel free to disagree and share your own opinions ...
Is there that many graphics formats left? It sounds like the code already exists, monstersgoboom just needs to add it to your fork of PCEAS. I don't see why an extra step helps, aside from some potential future format which might never exist.
|
|
|
Post by monstersgoboom on Mar 16, 2020 4:19:19 GMT
There's a few forks floating around. I forked jbrandwood/huc and added my changes to include .BMP file format ( the map editor I use only supports .BMP ! ) I'm curious if that's the most current ? As far as I can tell, my fork is the only "active" fork at the moment. Artemio still makes rare changes to his fork, and I just updated mine yesterday with his final change from last year. It's absolutely great to see that you're willing to dig into the code and make updates/changes yourself, we've sadly-lacked programmers who are willing to take things into their own hands and help to improve HuC. Having said which ... I had no idea that anyone needed .BMP support in PCEAS, it's never been mentioned before. I already have .BMP reading/writing code from long, long ago, which I've been updating to work in a new standalone grahpics converter program to add to the HuC tools. As such, I'd kinda rather not add .BMP format support to my fork of PCEAS at this point, unless someone can make a good argument for why it should be there. IMHO, for the long-term future of HuC, and assembly-language development on the PCE in general, we'd be better off having a separate open-source graphics converter added to the HuC distribution rather than keep on adding graphics converters into PCEAS itself. Everyone please feel free to disagree and share your own opinions ... Generally I'd say yes a more general tool is a better option. I do have tool I wrote for other consoles that I've added PC engine tile format for too, that's for meta tiles and removing repeats and finding tile matches with different palettes. I've ran into a few gotchas with pceas image import so I'll probably focus on that tool ( and share the repo when I can ) I was more interested in making sure I'm using the most current fork,rather than submitting a PR. If other people wanted BMP it surprises me this is the first you're hearing of it.
|
|
|
Post by monstersgoboom on Mar 16, 2020 4:27:51 GMT
I also like BMP, but only if the various forms of it are supported (mono is very rarely supported...). I’d be happy to get it converted to a PCE binary to include, instead of directly including and converting inline, as you suggest. My fork currently only supports 4bpp and 8bpp , mono would be trivial to add ( how would you specify what palette entry to use though ? )
|
|
|
Post by dshadoff on Mar 16, 2020 7:43:54 GMT
This is one of the challenges with direct imports as opposed to a separate tool; when using a separate tool, a new command syntax (optional paramater for example) can be added; with an existing ".INCxxx" structure, it may not be so easy.
But for mono, I'd make the assumption that the "0" color maps to the zero'th palette entry (as it's likely intended to be transparent anyway), and the "1" color is the one to be specified.
|
|
|
Post by turboxray on Mar 18, 2020 15:05:46 GMT
Are you building for windows or *nix? My Mac complains about implicit declaration errors, which was a little annoying, but windows build under mingw throws a fit for the makefiles. I had to edit a lot of them to get it to build. There was also a reference to 'cut' in the Date variable in make, which doesn't exist on cmd or powershell. Are people only using cygwin for window builds of HuC? Edit: "- no support for MinGW (Windows users are recommended to use Cygwin)" Okay. Since I was able to get it to build with MinGW, maybe I'll add some if/else logic to the makefiles for that environment.
|
|
|
Post by monstersgoboom on Mar 18, 2020 17:41:22 GMT
Are you building for windows or *nix? My Mac complains about implicit declaration errors, which was a little annoying, but windows build under mingw throws a fit for the makefiles. I had to edit a lot of them to get it to build. There was also a reference to 'cut' in the Date variable in make, which doesn't exist on cmd or powershell. Are people only using cygwin for window builds of HuC? Edit: "- no support for MinGW (Windows users are recommended to use Cygwin)" Okay. Since I was able to get it to build with MinGW, maybe I'll add some if/else logic to the makefiles for that environment. I'm building with mingw , sorry it looks like i missed a file in the push . I changed src\Make_src.inc to include this line CC = gcc
|
|
|
Post by elmer on Mar 18, 2020 18:06:46 GMT
Edit: "- no support for MinGW (Windows users are recommended to use Cygwin)" It was actually you that helped to fix the MinGW build years ago. I build with msys2/mingw-w64, and *never* with cygwin. I have no idea if it even builds with cygwin anymore. As for CMD or PowerShell ... why-on-earth do you want to use those? MSYS2 and mingw-w64 is the current-best way of building Unix programs on Windows ( www.msys2.org/), cygwin has become pretty irrelevent.
|
|
|
Post by elmer on Mar 18, 2020 18:16:18 GMT
I changed src\Make_src.inc to include this line CC = gcc May I ask why? Some HuC users build on BSD systems, and then there are also people building on Mac.
|
|