Jump to content
Jagware

GroovyBee

Members
 View Profile  See their activity

  • Content count

    31

  • Joined

  • Last visited

Posts posted by GroovyBee

  10. Posted · Report reply

    Congrats on creating and releasing this tool, but when i saw the thread-title i thought it was about the Windows-based JagView-tool that was released 12 years ago by a polish developer and that allows to view the graphics (CRY or RGB) in a Jaguar binary. May i suggest that you change the name of your tool before it is widely spread?

     

    Thanks for the compliment. I'll change the name if I go back to the project.

  11. Posted · Report reply

    Nice idea !

     

    Thanks for the compliment.

     

    I agree with Matthias - there's already a well-known Jaguar tool with the same name. Why not something different? (JagPic, JagImage, Bmp2Jag...?)

     

    If I go back to the project I'll rename it.

     

    If you want maximum quality, you could use 24-bit mode on the Jaguar. On the other hand, if you want to stick to the color mode that's likely to be used in a real game (RGB16 or CRY), I've got some conversion code (including dithering) I can contribute if you need it :)

     

    True! But its a tool for game pixel artists to see how their work would look on real hardware. Most pixel artists I know always want to try something that I haven't implemented yet ;). So the tool allows them to experiment while I catch up or implement the code needed to drive the graphics.

  12. Posted · Report reply

    Cool stuff :).

     

    Thanks for the compliment.

     

    A couple of suggestions, if I may (feel free to ignore them at will!):

     

    Yay! I like suggestions :D.

     

    - Could you include the universal ROM header at the start of the ROM? It can help people identify that it's a ROM a lot.

     

    Sure can! Is there an "official" spec for it? To be honest I haven't really looked for that kind of information so apologies if its common knowledge.

     

    - Since a ROM file wastes a flash on skunkboards (or any other flash carts), could you include an option to create a COFF version or similar?

     

    Possible, but I'm not sure how to coax a COFF file out of the VBCC compiler system. I could just rewrite it to be 100% assembler which would allow a multitude of different output formats. The blank space in the padding is full of 0xFFs which is the default state of any modern erased flash device so any good programming algorithm would just kip 16 bit words of 0xFFFF in the source image.

     

    - Are you using dithering when converting from 24bpp to 16? (I had some experience of as I was involved in a product that displayed 16bpp bitmaps and they looked better with dithering during conversion).

     

    No dither in this version. In my mind its a tool for viewing in-game assets so I wouldn't want to add extra visual information that isn't present in the original image. Although losing colours information is expected and therefore fine ;).

     

    I can understand that this is a quick util for your convenience hacked up quick, so again ignore my suggestions if you want to move on :D.

     

    Feedback is always good.

  13. Posted · Report reply

    Find attached a utility I created at the weekend :-

     

    JagView.1.00F.zip

     

    It is a Windows GUI tool that will convert 24BPP Windows *.bmp file directly into a Jaguar ROM image that can be viewed in 16BPP on real hardware. Just press the "Browse..." button and choose an image and then use the "Convert" button to process it. A new file will be created that has a *.rom file extension. The ROM image is padded to the nearest 1MB so it can be used in emulators like VJ without conversion.

     

    Some notes :-

    Images must be 24BPP, 8BPP images are not supported at this time.

    Images larger than 320 c 200 (w x h) will be cropped to 320 x 200.

    Images smaller than 320 x 200 will be displayed in the centre of the screen.

     

    The utility is ideal for pixel artists who want to create in-game assets without needing a programmer to implement the features they need or to check out how screenshots or mock-ups would look.

     

    The application has been tested on XP fine and the ROMs on a PAL jaguar. (many thanks fto sh3-rg for testing)

     

    Load and execute the final ROM at 0x802000.

     

    Any problems let me know.

  14. Posted · Report reply

    If you just want a basic table then this will do it :-

     

    http://www.daycounter.com/Calculators/Sine...alculator.phtml

     

    if you want high level language then in "C" its something like this :-

     

    #define SIN_NO_OF_POINTS 60
#define SIN_SCALE 100
#define SIN_OFFSET 20

for (int c=0; c<SIN_NO_OF_POINTS; c++)
    {
    double angleInRadians=2*PI*(double)c/(double)SIN_NO_OF_POINTS;
    signed long int val=SIN_OFFSET+(signed long int)(sin(angleInRadians)*SIN_SCALE);
//... Process val here.
    }

     

    You'll need to include math.h to get the sine function. The value of PI might be defined in that header file too, if not you'll have to #define it yourself.

  16. Posted · Report reply

    In the file rand.s the function _srand starts as :-

     

    _srand:    
    move.l    d2,-(sp)
    move.l    #random_seeds,a0
    move.l    4(sp),d1
    move.l    d1,d2
    moveq    #RANDGEN_K,d0

     

    Which means that the new seed for the random number generator is actually the program counter of the instruction immediately after the "jsr _srand" in your program and not the new seed you passed to the function.

     

    It should be changed to :-

     

    _srand:    
    move.l    d2,-(sp)
    move.l    #random_seeds,a0
    move.l    4+4(sp),d1
    move.l    d1,d2
    moveq    #RANDGEN_K,d0

     

  17. Posted · Report reply

    Nice work GroovyBee!

     

    Thanks for the compliment!

     

    Glad to see some people using the VBCC I threw together for the Jag. I really should update it. But to be honest I didn't think people were using it anymore. I may take some time in the coming weeks to update it.

     

    Dr Typo is using it for his games. He has released the source code to them if you check out his game threads over on AA. Maybe its not a popular choice because without a standard library you have to reinvent the wheel for memory copy/fill and malloc etc. Although that shouldn't really be an excuse to not start coding on a platform.

     

  21. Posted · Report reply

    I always thought that VBCC was easier to use than gcc and could be great on Jaguar,

     

    I only downloaded VBCC a week ago on Sunday and up until that point I had no experience jag coding. I have used GCC for many years on several platforms and its very good for a free compiler system.

     

    because I had very hard time trying to compile rmvlib on windows using gcc

    congrats on using this with vbcc, should be a lot easier now to make games on jaguar using this lib !

     

    Thanks for the congratulations. I hope that more people will start coding for the jag. When the "C" version of Reboot's RAPTOR engine is available there will be even more choices :D.

  23. Posted · Report reply

    Does vbcc handle rodata and data sections?

     

    Yes! Read only data is placed along with the code in the .text section.

     

    And what about smac and sln?

     

    I dont think smac supports rodata but you can have constants in with the code. It does support .bss and .data sections. I haven't used sln because vbcc has its own linker.

     

    Do you need me to change the way I distribute the source files?

     

    Not yet! When all the code builds OK on windows we can look at joining both the source code branches back together again.

     

  24. Posted · Report reply

    Great! Thanks for doing this!

     

    Thanks for the compliment.

     

    I read quickly your first post. Are you sure it is needed to copy DATA section into RAM at startup?

     

    It is the programmer's responsibility to decide where variables go. As an example consider the following "C" statements declaring several variables :-

     

    unsigned long int wilma;

    unsigned long int betty=0xF00D;

    const unsigned long int fred=0xABBAD00;

     

    1) unsigned long int wilma;

     

    The variable "wilma" will be placed in the BSS section and its 4 bytes zeroed on initialisation.

     

    2) unsigned long int betty=0xF00D;

     

    The variable "betty" will be placed in the DATA section and the value 0xF00D will be copied to its 4 RAM locations on initialisation.

     

    3) const unsigned long int fred=0xABBAD00;

     

    Because of the const keyword the variable "fred" will be placed in RODATA if the section exists. If the compiler doesn't support RODATA it will be placed in the TEXT/CODE sections instead.

     

    If I try and do :-

     

    fred=0xCAFE;

     

    in the code the compiler displays the error "assignment to constant type".

     

    I added the 3 "C" lines above to example1.c and enabled the symbol table and made a cart ROM image. The symbol table contained :-

     

    Symbols of .text:

    ...

    _fred: global reloc, value 0x80e7e4, size 0

     

    Symbols of .data:

    ...

    _betty: global reloc, value 0x24744, size 0

     

    Symbols of .bss:

    ...

    _wilma: global reloc, value 0x264d8, size 0

     

    Linker symbols:

    _TEXT_START: global abs, value 0x802000, size 0

    _TEXT_END: global abs, value 0x80e878, size 0

    _DATA_LOAD: global abs, value 0x80e878, size 0

    _DATA_START: global abs, value 0x4000, size 0

    _DATA_END: global abs, value 0x24748, size 0

    _DATA_SIZE: global abs, value 0x20748, size 0

    _BSS_START: global abs, value 0x24760, size 0

    _BSS_END: global abs, value 0x26c5c, size 0

    _BSS_SIZE: global abs, value 0x24fc, size 0

     

    Don't worry about the "size 0" it always states that. If you look at the "Linker symbols" section and compare the "values" e.g. address of the variables in the symbol table they are all placed in the expected sections.

     

×