Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

demonkatze

Members+
  • Content Count

    22
  • Joined

  • Days Won

    3

Posts posted by demonkatze


  1. 4 hours ago, mamesick said:

    CAVE and SSV are already included.

    I thought so. Thank you mamesick!

    4 hours ago, mamesick said:

    Personally, I find that underclock hack too outdated, it's 15 years that is floating around......

    Wow... when I examined it, MAME version at that time was still about 0.84. :holeymoley:
    I don't know at all about this time.


  2. Hello, long time no see!

    Thank you so much as always. :cat:

     

    I tried some modify on neogeo raster hack.

    As far as I can confirm, this hack following problems have been fixed:

     

    - Garou : Extra round background animation loop sequence in Terry stage (https://mametesters....iew.php?id=3954)

    - Crosses Sword 2 : Sprite flickering

     

    (These are also fixed by current raster hack)

    - Riding Hero : Some lines on the bottom of the road

    - 2020 Super Baseball : '2020' text in attract mode

    - Viewpoint : Sammy logo effect in attract mode

     

    (These are works properly in official MAME, but broken by current raster hack)

    - Master of Shougi : Water effect in title screen

    - Sengoku 2 : One line at the bottom of the text zoom effect on the title screen

     

    I found that delaying vblank timing by one scanline fixes Garou and Crosses Sword 2 problems

    but I'm completely amateur so don't know the real hardware behavior so that's just guess.

    Actually applying vblank offset to Galaxy Fight, raster effect is rather off by one line.

    Therefore that's necessary not to apply to it.

     

    'MAX_SPRITES_PER_LINE' change seems only need for some homebrew games (e.g. Neo Pong, Shadow of the Beast Demo)

    but I think that these were may be originally created for emulators without sprite limit.

    modified_neogeo_raster_hack.diff.txt


  3.  

    So looks like the problem is here:

    void OptionsInit(void)
    {
    	// setup our INI folder
    	SetIniDir("ini");
    	// gamelist creation
    	game_opts.add_entries();
    	// now load the options and interface settings
    	LoadOptionsAndInterface();
    	// setup directory for datafiles in the Internal UI
    	SetDatsDir(GetDatsDir());
    }
    
    
    ?Specifically, these seems have broken during 0.187-0.188 development cycle:
    const char * GetDatsDir(void)
    {
    	return winui_opts.value(MUIOPTION_DATS_DIRECTORY);
    }
    
    void SetDatsDir(const char *path)
    {
    	winui_opts.set_value(MUIOPTION_DATS_DIRECTORY, path, OPTION_PRIORITY_CMDLINE);
    	ui_opts.set_value(OPTION_HISTORY_PATH, path, OPTION_PRIORITY_CMDLINE);
    	SaveInternalUI();	// ensure we store again the new dats dir for the core
    }
    
    
    I don't know what could happened, because all worked as expected in 0.187. Also, I'm still not able to reproduce this. My UI.INI didn't get corrupted and the value from INTERFACE.INI is correctly copied.

    Mistery.

    Found the problem and added a solution.

     

    The issue is that when you call 'set_value', it can corrupt the data you pass to it. So, "path" turned into garbage, so garbage was written to ui.ini.

     

    I made a temporary variable and copied "path" to it, then use the temporary variable on the 2nd write.

     

     

     

    It might be wise in the future to note that once any variable is passed to set_value, that variable becomes useless.

     

    That's good news!

    I'm glad that you found the cause. :cat:

     

    Anyway, it’s really mystery that it doesn’t occur depending on the environment.


  4. MAME? not ARCADE?

     

    Oops, I'm sorry to wrote incorrectly.

    It intended to write about ARCADE. (Corrected post #29)

     

    As I wrote in post #23, it doesn't happen in official MAME and even ARCADE 0.187 or earlier.

    What happens if you manually update ui.ini with a very long name. Does MAME or ARCADE corrupt it?

     

    Yes, even if I manually rewrite historypath in UI.ini, When ARCADE is started, it is automatically replaced with the directory set in datafile_directory in INTERFACE.ini.

    (and it's corrupted)

     

    I also tried ARCADE 0.187 and replaced it the same way, but it isn’t corrupted.

    (Maybe a problem has occurred during this replacement...?)


  5. I tried many times and it will definitely happen every time.
    Strangely, at the time of change directory and closed ARCADE, UI.ini isn't broken yet.
    Then it happen right after restart ARCADE.


  6. Thank you as always Robbert and Mamesick!

    About the bug that Chanbara said, I could test it on XP and 7 and reproduce it on both.

    'gui/interface.ini' has no problem but 'ini/ui.ini' gets broken.
    It happens in both 32 and 64 version ARCADE.

    I tried various directory names like these:

    C:\MAME Support\DATs	> NG
    C:\MAME_Support\DATs	> NG
    MAME Support\dats	> NG
    C:\test\dats		> OK
    c:\te st\dats		> OK
    dats			> OK
    dat s			> OK
    test\dats		> OK
    te st\dats		> OK
    test\test\dats		> OK
    test\test\test\dats	> NG
    aaaaaaaaaa\dats		> OK
    aaaaaaaaaaa\dats	> NG
    datttttttttttts		> OK
    dattttttttttttts	> NG
    

    It seems that bug is caused by the number of characters regardless of whether '\', ':' or space is included.
    I also tried double-byte characters and it was same result.
    (over 16 bytes with single-byte characters?)

     

    UPDATE:

     

    After that, I also tested plain official MAME and MAMEUI.

    In MAME, this bug didn't occur.

    In MAMEUI, it's more broken. Even if you open the directory dialog and press [Cancel] without making any changes, it will crash. (Some directories are displayed as garbled characters)
    In ARCADE, only broken historypath in UI.ini for some reason.

    And at 0.187 this bug doesn't seem to happen in any MAME.
    So it is certain that this happened with some change in 0.188.

    This is the only thing that I can do but I hope this will help.

    • Like 1

  7. Have you tried either to copy files in "ini/preset" folder to "ini" folder or to change any HLSL settings in "mame.ini" ?
    Preset in "mame.ini" has been deleted since any previous version, so If you haven't changed, even if enabled HLSL it doesn't do anything.

    I tried with ARCADE64 0.187 and both work fine.

     

    hmm... I can’t think of anything else.

    • Like 1

  8.  

    Robert, mameSick is this diff ok for taito_f3? I generated this from taito_f3 taken from arcade source versus offcial 186 source.

     

    Notice that - if (cx>=m_clip_al##pf_num && cx<m_clip_ar##pf_num && !(cx>=m_clip_bl##pf_num && cx<m_clip_br##pf_num)) \

    + if (cx>=m_clip_al##pf_num && cx<m_clip_ar##pf_num-1 && !(cx>=m_clip_bl##pf_num && cx<m_clip_br##pf_num)) \

     

    is still here:smile:

    Can some people test this out? I am totally hopeless at most games.

     

    I ran two MAME (changed this line or not) at a time and compare them side-by-side, but after all I couldn't find out what changed, either. Mystery...

    Anyhow I like this hack no matter what. Thank you Dink! :-)


  9. I don't remember what I did to fix it, but there weren't many changes needed. It took a while to find the bad code though.

     

    I have a plan to create a store2 repository to hold the MAME Plus! source code sometime in the future, so keep an eye out for that.

     

    Thank you for accepting my request! :-D


  10. Thank you so much for your work, Robert! :cat:
    I compiled and tested it there was no problem.

     

    By the way, if you don't mind may I have the source code or diff patch of MAME Plus! 0.168 fixed UI?


  11. After that I also tested till last boss myself (too difficult for me!) but you really helped me by testing it once more.
    Thank you so much again! :cat:


  12. Ahh, realizing too late. :down:
    Thank you for your trouble and testing too, haynor666 and mamesick.

    (Really I wanted to attach a file but I didn't know how to do. :oops: )


  13. I tried fixing 'START POSITION ERROR!!' message appeared in the bug reported place for now.

    • From the third level, if you die, the game hangs because the restart level is wrong. (MT #00377)
    • Go into the secret hole and die in the cave, you restart in a totally black area and you can't do anything. (MT #00205)

    There seems to be some mistakes in cchip mapping.
    There may be other parts of the same problem. (I haven't played this game too much :sweaty:)

    Here is diff patch for MAME 0.186:

    --- src\mame\machine\bonzeadv.cpp	2015-06-04 19:59:32.000000000 +0900
    +++ src\mame\machine\bonzeadv.cpp	2017-06-14 18:49:37.000000000 +0900
    @@ -65,7 +65,7 @@ static const struct cchip_mapping level0
     	{ 0x0a20, 0x0c80, 0x0000, 0x0100,   0x0a68, 0x0018, 0x0070, 0x0058 },
     	{ 0x0c80, 0x0e00, 0x0000, 0x0100,   0x0c40, 0x0018, 0x0070, 0x0040 },
     
    -	{ 0x0380, 0x07c0, 0x0100, 0x0200,   0x0038, 0x0418, 0x0070, 0x00a8 },
    +	{ 0x0380, 0x07c0, 0x0100, 0x0200,   0x0438, 0x0018, 0x0070, 0x00a8 },
     	{ 0xff }
     };
     
    @@ -97,17 +97,16 @@ static const struct cchip_mapping level0
     	{ 0x06e0, 0x0840, 0x04f4, 0x05f8,   0x0670, 0x0518, 0x0078, 0x0048 },
     	{ 0x0840, 0x0a10, 0x04f4, 0x05f8,   0x07d8, 0x0518, 0x0070, 0x0060 },
     	{ 0x0a10, 0x0b80, 0x04f4, 0x05f8,   0x09e8, 0x0500, 0x0080, 0x0080 },
    -	{ 0x0b80, 0x1090, 0x04f4, 0x05f8,   0x0b20, 0x0418, 0x0070, 0x0080 },
     
     	{ 0x0230, 0x03a0, 0x040c, 0x04f4,   0x02e8, 0x04b0, 0x0080, 0x0090 },
    -	{ 0x03a0, 0x03b0, 0x040c, 0x04f4,   0x0278, 0x0318, 0x0078, 0x00a8 },
    -	{ 0x0520, 0x08e0, 0x040c, 0x04f4,   0x0608, 0x0318, 0x0080, 0x0058 },
    -	{ 0x08e0, 0x0a00, 0x040c, 0x04f4,   0x0878, 0x0318, 0x0078, 0x0098 },
    +	{ 0x0840, 0x0b80, 0x040c, 0x04f4,   0x0908, 0x0418, 0x0078, 0x0030 },
    +	{ 0x0b80, 0x1090, 0x040c, 0x04f4,   0x0b20, 0x0418, 0x0070, 0x0080 },
     
     	{ 0x0230, 0x03b0, 0x02f8, 0x040c,   0x0278, 0x0318, 0x0078, 0x00a8 },
     	{ 0x03b0, 0x0520, 0x02f8, 0x040c,   0x0390, 0x0318, 0x0070, 0x00b8 },
     	{ 0x0520, 0x08e0, 0x02f8, 0x040c,   0x0608, 0x0318, 0x0080, 0x0058 },
    -	{ 0x08e0, 0x0a00, 0x02f8, 0x040c,   0x0878, 0x0318, 0x0078, 0x0098 }
    +	{ 0x08e0, 0x0a00, 0x02f8, 0x040c,   0x0878, 0x0318, 0x0078, 0x0098 },
    +	{ 0xff }
     };
     
     static const struct cchip_mapping level03[] =
    
    

    EDIT: I'm sorry. This patch I wrote yesterday is not correctly patched because tabs has been replaced by spaces.

    So If you saved this yesterday please try again.

    • Like 1

  14. mamesick, I'm the one who should thank you.
    Without your wonderful hack I wouldn't have been able to do it.
    Actually I’m not familiar with programming, but I'm happy if I have been helpful to you. :-D

    Robert, Thank you as always so fast release.
    Have a nice holiday! Please take your time and relax. :cat:


  15. I wrote this here along the flow of the conversation.

    Namco NB1 hack also breaks some graphics of Nebulas Ray.
    So I modified it a bit.

    namconb1_state::video_update_common in src/mame/video/namconb1.cpp

    // MAMEFX start
                if (m_pos_irq_level != 0 && pri >= 5) // raster interrupt enabled (special priority cases)
                {
                    if (pri == 5) c123_tilemap_draw( screen, bitmap, cliprect, pri );
                    if (cliprect.max_y == visarea_sprites.max_y) // no raster on sprites?? faster!
                    {
                        if (pri != 5) c123_tilemap_draw( screen, bitmap, visarea_sprites, pri );
                        c355_obj_draw(screen, bitmap, visarea_sprites, pri );
                    }
                }
                else
                {    
                    c123_tilemap_draw( screen, bitmap, cliprect, pri );
                    c355_obj_draw(screen, bitmap, cliprect, pri );
                }
    // MAMEFX end
    

    I tested Nebulas Ray and some other games and it's probably okay.


    And it isn't related to above hack

    TIMER_DEVICE_CALLBACK_MEMBER(namconb1_state::scantimer) in src/mame/drivers/namconb1.cpp

    m_screen->update_partial(posirq_scanline);
    

    Change to

    m_screen->update_partial(posirq_scanline - 1);
    

    This fixes stage 5 warp effect of Nebulas Ray. (You can also see it in attract demo)


    P.S. Sorry about my Google-translated lousy English :oops:

    • Like 1

  16. Thank you, Robert!
    By the way, I found a mistake in hack of 'src/video/taito_f3.cpp'.

    in 'void taito_f3_state::scanline_draw(bitmap_rgb32 &bitmap, const rectangle &cliprect)'

    ***** incorrect *****

    if(alpha_type==1)
    {
    if (m_f3_alpha_level_2as==0 && m_f3_alpha_level_2ad==255 && m_f3_game == GSEEKER) {
    alpha_mode=3; alpha_mode_flag |= 0x80;} /* will display continue screen in gseeker (mt 00026) */
    if (m_f3_alpha_level_2as==0 && m_f3_alpha_level_2ad==255) alpha_mode=0;

    else if(m_f3_alpha_level_2as==255 && m_f3_alpha_level_2ad==0 ) alpha_mode=1;
    }

    ***** correct *****

    if(alpha_type==1)
    {
    if (m_f3_alpha_level_2as==0 && m_f3_alpha_level_2ad==255)
    {
    if (m_f3_game == GSEEKER) /* will display continue screen in gseeker (mt 00026) */
    {
    alpha_mode=3;
    alpha_mode_flag |= 0x80;
    }
    else
    alpha_mode=0;
    }

    else if(m_f3_alpha_level_2as==255 && m_f3_alpha_level_2ad==0 ) alpha_mode=1;
    }

×
×
  • Create New...