Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

matmook

Members
 View Profile  See their activity

  • Content Count

    96

  • Joined

  • Last visited

Posts posted by matmook

  4. Posted

    17 minutes ago, 82-T/A said:

     

     

    Wow, this reminds me so much of the PC / Sound demos that different people would create back in the early to mid 1990s. I can't remember the names of them... but they were made to show-off the ability of VGA and the Sound Blaster. They were usually 320x200 and using the OPL2/3 chip on the Sound Blaster... hehe...

    Sound Blaster or Gravis Ultrasound or ... :D I did not follow the PC scene by that time for that... too many different configurations... 

    On ST it was easier, same configuration (but the ram sometimes) everywhere.

  9. Posted

    35 minutes ago, masteries said:

     

     

    Great game engine tool!

     

     

    Is this C capable game engine for Atari Jaguar suitable for port the Atari STE Metal Slug port?  xD  Port of a port...

     

    Can Atari Jaguar support 8 bit graphics? 

     

    Are preshifting sprites needed such on the STE?   If I can drop preshifting, 2 MB can be enough.

     

    What are the typical storage device? Cartridge or CD?

     

     

    Thanks,

     

    Well, 8bit is the best option. No preshifing (all is managed by the sprite engine). Cart max 6MB.

  10. Posted

    1 hour ago, LordKraken said:

    Great work! This is going to boost the homebrew community!

     

    Thanks for adding C, Basic is fun but well, I'm getting to old to go back to basic :)

     

    I've noticed a small issue, the first time I compile a project, virtual jaguar starts with a black screen. Then if I kill VJ and rebuild the project it works. I'm suspecting that VJ starts before the ROM is actually copied at the expected location, but I'll check that later today. By the way are you open to contribution?

    Well, this happens to me all the time on the first VJ call, (not with JagStudio and the binary is already in place). I think it's more a VJ issue than a JagStudio issue.

  11. Posted

    14 hours ago, Otto1980 said:

    ok i found it, and took a look at it.
    seems quiet usefull..

     

    But it you have some additional docs, feel free to share ;-)

    Ok thanks, found it, took a look at

    seems easy

     

    if you still have some rmotion docs, feel free to share :-Da

    Well, I was (am) too lazy to write a documentation (and nobody asked by that time :D ).

    Raptor's animation system is fast and efficient but if you need to use more complex animations (non-linear), rmotion may help you (ask me, it's always better with a use case).

     

     

     

     

     

  12. Posted

    7 hours ago, Otto1980 said:

    nice release, thanks

    i will take a closer look at, maybe this time i manage to start coding a little.
     

    little question..

    the rmotion.exe is for animation
    is there a little more information about it? i found not much details at included documentation and here at Atariage

     

    best regards

    Well, I will make a longer answer later (on my phone, boring), but you can start by looking at Raptor examples (2 of them use rmotion).

  13. Posted

    1 hour ago, swapd0 said:

    No, it takes the same time but you are doing an extra instruction for free but you are wasting 4 bytes (for addq and extra instruction).

    Okay, in this case that's interesting (got a very big loop with some of them so.. ).

     

    Thanks!

  14. Posted

    9 minutes ago, SCPCD said:

    Indexed and offset load/store take 2 more cycle (as wait_states) than standard load/store.

     

    Remplacing it with standard load/store and using addq can be more efficiency as you can rearange opcodes to avoid as much wait_states as possible (at least 1 for each load/store) :

    The idea is to replace the 2 wait_states by 1 addq and 1 another useful instruction.

     

     

    Okay, so if it's more efficient, it means 2 wait_states take more time than 1 addq and 1 another useful instruction (wait_state <> cycle) ?

  15. Posted

    1 minute ago, CyranoJ said:

    For the original code... it won't be.  However, those new instructions can prepare data or registers for the next chunk of code.

    Okay for the "Nop (or some other code)" (interleaving). But I also added "addq #4, r14" and for me it means more cycles used...?

     

  16. Posted

    Thanks SCPCD !! :)

     

    So the benefit of loadp/storep (if you can place/interleave them) is to avoid loosing, a second time, 10 extra cycles to access external memory when using 2 x load/store.

     

    Great! 

     

    For R14(5)+, I don't see the benefit. I know you are right but my brain doesn't want to understand that...

     

    Let's take an example:

    Load (14+1), r0

    Load (r14+2), r1

     

    If I want to avoid those R14(5)+, can I do:

    Load (r14), r0

    Nop (or some other code to not touch r14)

    Addq #4, r14

    Nop (or some other code to be sure r14 is updated)

    Load (r14), r1

     

    I will avoid extra wait_states but add new instructions, how could it be faster in that case? Oo

     

     

     

    • Like 1

  17. Posted

    Hi!

     

    I was just wondering if there is a list if GPU good practices... (SCPCD knows I think :D )

     

    I know some basic code interlacing rules but I'm not sure for loadp/storep, load/store using r14+/r15+, ... what to avoid and what to use instead...

     

    Thanks! :)

  18. Posted

    1 hour ago, LinkoVitch said:

    It might still be that dodgy crap sound code you are using! :D :D 
     

    Please don't assume my code is free from bugs, hopefully you haven't found a new one, but it's still possible it's become upset for some reason.  If it happens again, maybe just reset the system and see if a really simple test code works correctly too (perhaps the playback demo in the sound engine zip).  If that screws up then it's probably not the SE, if that works fine, then could be the SE is getting upset for some reason.

    I know you can make great bugs :D but this time it survives reset and power cycling .. sadly I won't be able to blame you!!! 😛

    • Haha 2

  19. Posted

    6 minutes ago, Zerosquare said:

    I hope it's just a capacitor problem.

     

    I had a Jaguar with similar crashing and audio issues that I couldn't fix - replacing the capacitors didn't help.

    I hope it's just that too! If not I'll try to replace the DSP (or I will ask you!!! :D ).

  20. Posted

    11 minutes ago, neo_rg said:

    Can desolder you one from one of my Jaguar motherboards that I use for parts.

    I will just do a recap first before doing a DSP replacement.

    I'm not very confident at soldering and it's the only unit I have so as long as it works, I can code! :)

     

    But that's nice, thanks!

  21. Posted

    Well, I think I had the same issue just 10 minutes ago. I was testing some code this morning, everything was fine, got sound and pad management using Linko's dsp library and suddenly no more sound/pad.

     

    Done some reset, power off/on, pad is working in the bjl bios (but that's 68k code) but no sound/pad in my game.

     

    Unplugged everything, waited 2 minutes, plugged the whole thing again and everything worked again as expected..  maybe it's recap time...!

     

     

    • Like 1

  23. Posted

    8 hours ago, swapd0 said:

    Just to avoid to open a new topic.

     

    Sometimes when I load a partial CLUT I got some colors wrong, anyone has the same problem? Sometimes it works, others it fails. This is the source code.

      

    void set_palette(int16_t index, int16_t items, uint16_t *color)
{
	volatile uint16_t *clut = (uint16_t *)CLUT + index;
	while ( items-- )
		*clut++ = *color++;
}

    Maybe it's better to update the CLUT on the vbl interrupt?

    Well, I would check the index value...

    Do you have the "Sometimes when I load a partial CLUT I got some colors wrong" calling code?

     

     

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...