Sega Master System / Mark III / Game Gear|
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats
Music - Videos - Development - Translations - Homebrew
|Goto page Previous 1, 2, 3, 4, 5 Next|
Test build 2011-08-21Posted: Sun Aug 21, 2011 6:14 pm
Attached a new build
- Updated meka.nam with lots of stuff.
- Fixed ABOUT box crashing.
- Fixed rendering when VDP display is disabled and backdrop color rendering.
- Early TilemapViewer support for video mode 2 used by SG-1000 games, etc.
- Fixed a glitches in FileBrowser when using the mouse to open the ".." directory.
- Fixed light phaser hit position in game mode.
- SMS/GG ROM images smaller than 48KB default to using no mapper.
- Added support for variant of MSX-based Korean 8KB mapper used by Nemesis.
*EDIT* Build updated with a minor fix.
||Posted: Tue Sep 06, 2011 8:19 pm|
|Oh man, new MEKA is much slower. There is a way to force to start MEKA in Fullscreen instead of Windowed?|
||Posted: Tue Sep 06, 2011 8:26 pm|
ALT-ENTER switch to Fullscreen, it should be saved.
How slower ? Whats your framerate ? (and your CPU/video card, roughly)
There's still various issues to solve with different video drivers etc but maybe your computer has such issue, in which case I'd be happy to look for a fix.
||Posted: Sun Sep 11, 2011 2:40 am|
Done a quick check on what one I was playing and was Hang On / Safari Hunt one, so my bad. So checked the other one as you suggested and no problems (like on actual hardware).
Anyway sorry for not getting back to you on it sooner.
||Posted: Sun Sep 11, 2011 10:09 pm|
I made lots of fixes to the codebase today and got MEKA to compile and work on MacOSX with sound using the Makefile. There's still issues due to the missing X86 files that i will fix soon (as i have now bought and using a Mac).
||Posted: Sun Sep 11, 2011 11:03 pm|
|I have now implemented the Decode_Tile() function in C so it should work on non X86 machines.|
||Posted: Fri Sep 23, 2011 6:04 pm|
|Again, MEKA is slower. I was running on a Pentium 4 at 2.66 Ghz and my video card is VIA/S3G UniChrome Pro IGP.|
||Posted: Fri Sep 23, 2011 8:41 pm|
How slower? What is the framerate unthrottled?
Are you using directx or opengl driver?
There's lots of issues with the video system right now so any precision is welcome.
||Posted: Fri Sep 23, 2011 11:29 pm|
Just I starts the exe and MEKA was going on a black window... And it drain my free DRAM quickly and the only thing that I do, is summon the Windows Task Manager. I was using DirectX 9.0c and OpenGL on my PC is much slower (I was used on NO$ZOOMER and my PC freeze).
And I was executed the setup.bat and nothing was appeared at boxes.
||Posted: Fri Sep 23, 2011 11:44 pm|
It sounds tricky to find the reason of that bug.. hmm.
Could you please try to edit mekaw.cfg and change the video driver to use OpenGL instead?
Find the 'video_driver = directx' line and change to:
video_driver = opengl
Thanks a lot!
Yes sorry this was broken, i will fix it soon hopefully.
||Posted: Sat Sep 24, 2011 12:19 am|
Again, is slower.
And MEKA don't create a config file at all times (I copied from 0.73).
||Posted: Sat Sep 24, 2011 9:47 am|
You said previously it ran on a black window. I don't understand clearly. What it showing the interface? What kind of framerate do you have? (you can press CTRL-F to see framerate)
It is faster if:
- you press ESC to switch to game only mode?
- you stay in interface and close all windows apart from game window?
Posted: Sat Sep 24, 2011 5:27 pm
Last edited by Sonic of 8! on Sat Sep 24, 2011 5:30 pm; edited 1 time in total
|No. And I thin that MEKA runs a frame at 40 sec.|
||Posted: Sat Sep 24, 2011 9:31 pm|
|On my new Mac running Vista it also runs at 40 FPS which is strange. I will investigate the problem.|
||Posted: Sun Sep 25, 2011 1:57 am|
OK, I wait.
But a request: Add the Hidden FM PAR Codes that found by me at meka.pat file, please (found in Super Basketball FM VGM Pack, I think)?
||Posted: Sun Sep 25, 2011 10:58 am|
Yes that's cool. Can you send me new lines to add to meka.pat? other games that Super Basketball? (i forgot if there was other games you found it on)
||Posted: Sun Sep 25, 2011 7:27 pm|
I cannot send the codes in a meka.pat form, because I was in a Mobile WAP Connection. But, there is the codes:
Battle Out Run: 00DE00:01
Double Hawk: 00DD00:01
Dynamite Dux: 00D000:01
Rambo III: 00DE80:01
Summer Games: 00C001:01
||Posted: Sun Sep 25, 2011 11:51 pm|
|Lovely, that's quite an impressive amount of games. I didn't know about some of them.|
||Posted: Wed Oct 05, 2011 7:58 am|
Sorry for the late response but I just read this thread again. I'll try to have a look soon.
Please also consider installing VirtualBox on the Mac and run a Linux distribution inside it.
Thanks for your hard work on meka.
||Posted: Sun Oct 09, 2011 1:54 pm|
That's what I found out trying to compile latest svn on a Fedora 15/x86_64:
If you set SYSTEM = unix in the Makefile you get the following error:
g++ -I. -Ilibs -I../include -DARCH_UNIX -DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE -Wall -O3 -ffast-math -fno-strength-reduce -funroll-all-loops -fomit-frame-pointer -c tvtype.c -oobj/tvtype.o
make: *** No rule to make target `obj/mappersa.o', needed by `../meka'. Stop.
If you set X86_ASM = no in the unix section, it will compile but it won't link because an ix86 system seems to be still needed to compile meka.
/usr/bin/ld: i386 architecture of input file `obj/eagle.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `obj/hq2x16.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `obj/hq2x32.o' is incompatible with i386:x86-64 output
obj/debugger.o: In function `Debugger_Applet_Layout(bool)':
debugger.c:(.text+0x47a): undefined reference to `al_set_target_bitmap'
debugger.c:(.text+0x48f): undefined reference to `al_clear_to_color'
Bock, will meka support x86_64 systems? If yes, I'll have another look when the transition will be made. Otherwise, I'll try to get my hands on a ix86 system to make further tests.
||Posted: Sun Oct 09, 2011 10:31 pm|
|Can you remove mappersa.o and the other files from the link list? They aren't used required AFAIK.|
||Posted: Sat Oct 15, 2011 6:07 pm|
The latest svn has some problems with the makefile:
make: *** No rule to make target `z80marat/Z80DebugHelpers.c', needed by `obj/z80marat.a'. Stop.
This is due to the fact that Z80DebugHelpers is a cpp file, but even correcting this issue didn't get me far.
So I did my test against svn r305. With this patched Makefile I could compile meka under Fedora 15 on a x86_64 system:
$ svn diff
--- srcs/Makefile (revision 305)
+++ srcs/Makefile (working copy)
@@ -36,8 +36,8 @@
# SYSTEM = dos
# SYSTEM = win32
-# SYSTEM = unix
-SYSTEM = macosx
+SYSTEM = unix
+# SYSTEM = macosx
BUILD = release
# BUILD = debug
@@ -84,9 +84,9 @@
MV = mv
MKDIR = mkdir
-DEF_OS = -DARCH_UNIX -DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE
+DEF_OS = -DARCH_UNIX #-DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE
INC_OS = -Ilibs -I../include
-X86_ASM = yes
+X86_ASM = no
LIB_OS = -Llibs -L/usr/X11R6/lib -lX11 -lXext -lm -lpthread -L../lib # This may require an update
LIB_OS += -lXcursor -lXpm
@@ -187,7 +187,8 @@
ifeq ($(SYSTEM), unix)
-LIB_ALLEG = `allegro-config --libs`
+#LIB_ALLEG = `allegro-config --libs`
+LIB_ALLEG = -lallegro -lallegro_font -lallegro_audio -lallegro_primitives -lallegro_main -lallegro_image
ifeq ($(SYSTEM), macosx)
@@ -217,7 +218,8 @@
OBJ_FEAT = $(OD)/checksum.o $(OD)/db.o $(OD)/vlfn.o $(OD)/patch.o $(OD)/saves.o
OBJ_CFG = $(OD)/config.o
OBJ_MISC = $(OD)/allegro4to5.o $(OD)/misc.o $(OD)/build.o $(OD)/fonts.o $(OD)/file.o $(OD)/data.o $(OD)/tools.o $(OD)/keyinfo.o $(OD)/drivers.o $(OD)/message.o $(OD)/capture.o $(OD)/errors.o $(OD)/sdsc.o $(OD)/setup.o
-OBJ_BLIT = $(OD)/blit.o $(OD)/blitintf.o $(OD)/eagle.o $(OD)/hq2x.o $(OD)/hq2x16.o $(OD)/hq2x32.o
+#OBJ_BLIT = $(OD)/blit.o $(OD)/blitintf.o $(OD)/eagle.o $(OD)/hq2x.o $(OD)/hq2x16.o $(OD)/hq2x32.o
+OBJ_BLIT = $(OD)/blit.o $(OD)/blitintf.o $(OD)/hq2x.o
OBJ_CPU = $(OD)/machine.o $(OD)/cpu.o
OBJ_VIDEO = $(OD)/video.o $(OD)/video_m2.o $(OD)/video_m5.o $(OD)/video_c.o $(OD)/vdp.o $(OD)/palette.o $(OD)/effects.o $(OD)/fskipper.o
OBJ_MACH = $(OD)/sg1ksc3k.o $(OD)/sf7000.o $(OD)/coleco.o $(OD)/fdc765.o
Please note that allegro-config is no longer available under allegro5 AFAIK therefore I had to explicitly specify the libraries as you did for the Mac.
Then I could run meka. I heard sound - a very good think for me after all these years of silence :-)
Problem I noticed:
* the fullscreen option isn't really a fullscreen - it just uses the entire meka window for the emulator window
* I couldn't use the joystick although it seems correctly detected at startup
* Pressing CTRL + ALT + arrow keys (required by some games like wonderboy in monsterland makes Fedora switching workplace - this is really annoying
||Posted: Sun Oct 16, 2011 12:15 pm|
The latest svn has some problems with the makefile:
make: *** No rule to make target `z80marat/Z80DebugHelpers.c', needed by `obj/z80marat.a'. Stop.
This is due to the fact that Z80DebugHelpers is a cpp file, but even correcting this issue didn't get me far.[/quote]
This you did try adding this file in the object list?
The makefile it is bound to always have missing or non-existing files here because I don't use it. It should be trivial to update that list when a file gets added or removed but i tend to forget it since i don't use the Makefile myself.
All the files in Meka sources are now C++ even though their extension is .c. The makefile should be calling g++ and eventually i will rename this.
Great to hear it is running :)
I will apply your patch thanks!
I have been comtemplating changing the default buttons to Z/X instead of CTRL/ALT.
Are you able to investigate the joystick problem further?
Thanks! Exciting times!
||Posted: Sun Oct 16, 2011 6:37 pm|
Now it uses pkg-config. Something like this:
pkg-config --libs allegro-5.0 allegro_image-5.0
I didn't test this version because I use Debian (testing version) and it doesn't have Allegro5 in its packages =P
But at version 0.70, while running meka fullscreen at my wide-screen, the image is rendered with wrong aspect ratio (distortion/stretch)[/code]
||Posted: Sun Oct 16, 2011 7:21 pm|
Pressing ESCAPE switch between rendering the GUI or the Game only.
Pressing ALT-ENTER enable fullscreen mode (in either of them)
||Posted: Sun Oct 23, 2011 6:11 pm|
Some updates. I am still using r305 because I haven't yet found the time to have a closer look at the problem there are with HEAD under Linux.
The joystick problem is probably caused by the meka.inp file. By default Joypad 1 is "stick #2". If have only one stick you'll have to manually configure the Joypad. After doing this the joystick works as expected. Probably this setting can be better detected.
I can go to fullscreen pressing ALT+ENTER, but pressing these keys again will render the Gnome session broken. The screen will be restored to your previous resolution, but you can only see a portion of the screen of the size of the meka fullscreen window (I think it was 800x600 in my case), the rest of the screen is black and you cannot access it.
Using pkg-config to detect allegro libraries works as RodolfoRG kindly noticed.
Test build 2011-10-23Posted: Sun Oct 23, 2011 7:29 pm
Sonicof8: can you tell me if the performance are better now?
I also added options in the Setup screen so maybe you can try different drivers (DirectX/OpenGL).
Changes since previous build:
- Preliminary MacOSX port. [Omar]
- Changed default key mapping for Player 1 buttons to use Z/X. [Omar]
- Setup panel allows to select display driver and resolution. [Omar]
- Added support for 4 PAK All Action mapper. [Omar]
- Hardware reset leaves RAM cleared with $F0 patterns on Japanese SMS.
This allow 'Ali Baba' to run properly. Better clearing pattern could be
implemented for other systems/countries after we've done more research. [Omar]
- Added support for mirrored VDP ports in $80..$BF range, as required by some
Korean games such as 'Pooyan', 'Sky Jaguar' or 'E.I.'. [Omar]
- Added CR command ("Continue to next RET* instruction"). [Omar]
- Improved the range of disassembly before PC cursor when running loops. [Omar]
- TileViewer: support for showing full 16 KB range of tiles in legacy graphic modes. [Omar]
My next priority is to fix sound for non-60 Hz modes and get rid of the sound latency issues that accumulate sometimes.
||Posted: Mon Oct 24, 2011 12:05 am|
Wow, this was a pain to get going...
First, you have to checkout about 500 MB worth of files for Allegro. There's two hours shot to hell. Then the code needs fixing to compile on linux.
Rename: "srcs/z80marat/Z80DebugHelpers.cpp" to "srcs/z80marat/Z80DebugHelpers.c"
Next edit the Makefile:
# Option : Debugger
OBJ_CPU += $(OD)/debug.o $(OD)/debugger.o $(OD)/debughelper.o $(OD)/datadump.o
See that $(OD)/debughelper.o? That's new...
$(OD)/debug.o : z80marat/Debug.c z80marat/Z80.h
$(CC) $(CFLAGS) -c z80marat/Debug.c $(CC_OUT)$@
$(OD)/debughelper.o : z80marat/Z80DebugHelpers.c z80marat/Z80.h
$(CC) $(CFLAGS) -c z80marat/Z80DebugHelpers.c $(CC_OUT)$@
If you don't make that debughelper.o for after debugger.o, debugger.o fails during link saying the function in Z80DebugHelpers.c is missing. The z80marat.a looks like it was SUPPOSED to have that file, but it doesn't because it's not making an archive, it's merely making Z80.c:
$(CC) $(CFLAGS) z80marat/Z80.c $(CC_OUT)$@
See that? It compiles Z80.c to the output name (z80marat.a) and that's it!
Make those changes and now it compiles!! And promptly aborts due to a buffer overflow... which if you look into it closer is NOT a buffer overflow. The crazy nuts who maintain libc have added a thing called "Fortify" that checks for buffer overflows on "dangerous" commands... except they don't - they look for POSSIBLE buffer overflows and abort if one is POSSIBLE, not if it really occurs! So the realpath() command in the file init function was aborting because a buffer overflow was POSSIBLE.
So back to the editor... change the CFLAGS:
DEF_OS = -DARCH_UNIX -D_FORTIFY_SOURCE=0 #-DX86_ASM -DASM_SYMBOLS_REQUIRE_UNDERSCORE
That "-D_FORTIFY_SOURCE=0" turns off the checking in libc. And NOW it runs... at one frame per second. Even the gui is only running one frame per second. What kind of requirements does meka have? I'm running a 1.6 GHz CoreDuo with 945GM chipset/video. That should be WAY more than is needed for an SMS emulator. I can run N64 emulators on it! Maybe it's a timing error...
||Posted: Mon Oct 24, 2011 12:31 am|
Can't you get precompiled Allegro binaries+header somewhere?
I don't quite understand the need for all of this apart from the initial renaming (which is due to the fact that the Makefile doesn't have rules for .cpp files). If you just rename to .c what happens?
I will look into fixing that. Can you tell of other functions that are tagged as unsafe by the library you are using?
It is certainly an issue we have to fix but it should be running decently fast. During the porting to Allegro 5 i had a lot of problems to deal with with the fact that Allegro 5 currently doesn't have any software rasterizer which leads to a lot of CPU<>GPU transfers given how Meka render some buffers. The problems is that Allegro does a lot of voodoo magic in our back instead of notifying of performances issues, so often things appears to works but of course they are very slow.
For reference, on my new iMac running Windows 7 playing Psycho Fox with GUI disabled, unthrottled 1/1, I get 350 FPS with DirectX driver and 1200 FPS with OpenGL. One could argue it should be way faster than that but its reasonably enough. The problem is that it takes one occurence of Allegro does black voodoo magic somewhere in the pipe to bottleneck everything down.
- Do you get performance difference in GUI and Game mode (pressing Escape?)
- In meka.c look for :
g_configuration.video_game_format_request = ALLEGRO_PIXEL_FORMAT_ANY_16_NO_ALPHA;
g_configuration.video_gui_format_request = ALLEGRO_PIXEL_FORMAT_ANY_NO_ALPHA;
Can you experiment changing those values (respectively for game and GUI modes) with some of the other Allegro defines and see if it does better?
Namely, trying without the NO_ALPHA variants, or trying the GUI format to match the game format, etc. But the pixel format for 'video_game_format_request' has to be a 16-bits format for now.
Thanks a lot for your help :)
||Posted: Mon Oct 24, 2011 12:40 am|
I' d be so happy if it used SDL instead of Allegro... ;)
I could help on it if you want to (except sound :P)
||Posted: Mon Oct 24, 2011 6:13 am|
4.x, not 5.x. That wasn't too bad other than all the junk the document dependencies pulled.
If you just rename the file, everything compiles, but when it goes to link meka, it gives an error that debugger.o couldn't find Z80DebugHelper_IsRetExecuting(). I gave the reason why - the file that function is in is not linked into the executable. My debughelper.o target provides the file that has that function.
There's a method to print all the functions discussed along with fortify here:
No, it runs the same speed. Might be something in allegro... maybe I needed to set some flag when I compiled it. I could just see them using a software renderer unless you tell it otherwise. :D
I'll try a few things to see if I can't find the issue and report back. Thanks for the tips. :)
||Posted: Mon Oct 24, 2011 8:50 am|
I (or you should be able to) will fix the Makefile to get rid of the library and just link all the Z80 stuff as regular objects files directly
Allegro 5 does actually have a software renderer my bad for the confusion, it is just that it is extremely slow. A lot of things in Allegro 5 seems terribly slow when I browse the code, i was a bit disappointed by the state of things to be honnest. Although doing the Allegro 5 port made MEKA much closer to be able to use lower-level library such as SDL so maybe I'll eventually switch to that.
||Posted: Fri Oct 28, 2011 2:49 am|
|Found my problem - it's the throttling. When I turn it to unthrottled, it's "full speed" - I put it in quotes because my old 1.6GHz CoreDuo isn't fast enough to run it at 60 Hz. I probably get 40 to 50 Hz out of it. So if you try to throttle on a slow system, it goes HORRIBLY SLOW!|
||Posted: Fri Oct 28, 2011 8:45 am|
Thanks for the pointer, i will look into that. Were you able to tweak the video format parameters by any chance?
||Posted: Fri Oct 28, 2011 9:00 am|
|Note that it seems OK (if not full speed in the UI) on my 800MHz Atom CPU.|
||Posted: Fri Oct 28, 2011 5:27 pm|
I've tried a few things, but the only thing that seems to make a difference between allegro and meka is the frameskip.
Oh - I just noticed something in the meka makefile... it doesn't turn on X86_ASM for the unix target. I should enable that and recompile.
And... it makes almost no difference. Any suggestions?
||Posted: Fri Oct 28, 2011 5:56 pm|
|X86 code has a completely minor effect, in fact i am about to delete most of it. The slowdown seems to be do to Allegro locking/unlocking too many bitmaps. I'm working on it.|
||Posted: Fri Oct 28, 2011 6:06 pm|
Okay, I'll keep an eye on updates then. Nice work so far - it seems pretty solid, if a bit slow on my PC. :)
||Posted: Fri Oct 28, 2011 10:13 pm|
|Sorry about a new release with no response. But tomorrow I test this.|
||Posted: Sat Oct 29, 2011 6:59 pm|
A #000000 (black) screen again (all of three video modes). And sometimes it gives a error.
||Posted: Sun Oct 30, 2011 11:03 am|
What do you mean "again" ? You said it was slow the last time, not a black screen. What error does it give?
||Posted: Sun Oct 30, 2011 3:05 pm|
|Sometimes, the window came black or transparent. And the error is one of that was give an instruction error on 0x???????... And may give the options of close or debugging the program. And again, slow.|
||Posted: Sun Oct 30, 2011 3:12 pm|
Which window, the full MEKA window or the game window in the interface?
How can you tell that something is slow if it doesn't show?
When does the error show?
||Posted: Sun Oct 30, 2011 3:57 pm|
MEKA goes slow on interface. For a example, it don't show all the options/windows at time.
The error appears with:
A memória não pode ser "writen" (the memory cannot be "writen").
I might think that when mekaw was created the cfg and another files like meka.dsk, he tries to open but the mekaw don't was concluded themselves.
Later, I can record a video on my Mobile Phone, and I show how MEKA is slow.
||Posted: Sun Oct 30, 2011 5:18 pm|
|Edit the config file and set it to unthrottled. Super-slow meka was (for me, at least) an issue with the throttle speed code.|
||Posted: Sun Oct 30, 2011 5:50 pm|
|Nope. The problem remains.|
||Posted: Sun Oct 30, 2011 8:25 pm|
So, I finally decided to try this here (it means: compile allegro 5 by myself - as said, Debian doenst have it on its repositories).
I have the same issue mentioned about the file z80marat/Z80DebugHelpers.c as rule for $(OD)/z80marat.a: it doesn't exist . The real file has the .cpp extension. So I renamed the file, as its actually a .c file anyway.
I got a lot of warnings about enumeration values not being handled by switch statements, but I didn't look at them.
There were simple mistakes that usually don't harm anyone, like:
capture.c:79:21: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
I don't know if v_start field is used when there's no scroll, but here's a warning:
g_widget.c: In function ‘void widget_scrollbar_update(t_widget*)’:
g_widget.c:498:13: warning: ‘v_start’ may be used uninitialized in this function [-Wuninitialized]
app_cheatfinder.c: In function ‘u32 _ZL21CheatFinder_ReadValueP14t_cheat_finderPK14t_memory_rangeP20t_cheat_finder_match.isra.1(const t_memory_range*, t_cheat_finder_match*)’:
app_cheatfinder.c:409:9: warning: ‘v’ may be used uninitialized in this function [-Wuninitialized]
As I use x86_64 architecture, I always pay attetion for error like that:
g_menu_i.c: In function ‘void gui_menus_init()’:
g_menu_i.c:157:136: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
app_cheatfinder.c:167:181: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
app_cheatfinder.c:192:153: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
app_cheatfinder.c:207:178: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
app_cheatfinder.c: In function ‘void CheatFinder_Update(t_cheat_finder*)’:
app_cheatfinder.c:318:43: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
app_cheatfinder.c:346:42: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Then I got another compilation error:
app_cheatfinder.c: In function ‘void CheatFinder_CallbackMemtypeSelect(t_widget*)’:
app_cheatfinder.c:535:40: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
app_cheatfinder.c: In function ‘void CheatFinder_CallbackValuetypeSelect(t_widget*)’:
app_cheatfinder.c:541:54: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
app_cheatfinder.c: In function ‘void CheatFinder_CallbackComparerSelect(t_widget*)’:
app_cheatfinder.c:547:51: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
app_cheatfinder.c: In function ‘void CheatFinder_CallbackCompareToSelect(t_widget*)’:
app_cheatfinder.c:553:55: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
app_cheatfinder.c: In function ‘void CheatFinder_CallbackSelectOneMatch(t_widget*)’:
app_cheatfinder.c:580:34: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
app_memview.c: In function ‘void MemoryViewer_ViewPaneCallback(t_widget*)’:
app_memview.c:627:49: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
We should avoid those pointer<->integer conversions for portability ;) Maybe you should make a struct+union to check when it's a real pointer or just an integer? Here, for a quick (and so ugly) fix, I've change it for (long).
In the Makefile, I've removed all the LIB_OS definitions for unix target, leaving it empty: they were useless and cause a link error here.
I've also changed the line for Allegro flags:
LIB_ALLEG = `pkg-config --cflags --libs allegro-5.0 allegro_image-5.0 allegro_audio-5.0 allegro_font-5.0 allegro_primitives-5.0`
I've got the same error said (and solved) by Chilly Willy.
obj/debugger.o: In function `Debugger_Hook(Z80*)':
debugger.c:(.text+0x4634): undefined reference to `Z80DebugHelper_IsRetExecuting(Z80 const*)'
collect2: ld returned 1 exit status
I did what he said and it works.
And when everything compiled... No Meka sound :P It keeps still when
Initializing sound system...
- Initializing sound card @ 44100 Hz
I can't launch Meka... =/
||Posted: Sun Oct 30, 2011 9:58 pm|
Thanks for your help. If you can make a patch with some of the change I'll apply them. I guess i should get myself a Linux box sometimes :)
Can you run with GDB and see where it hangs?
Thanks a lot!
||Posted: Sun Oct 30, 2011 10:04 pm|
I'll try to clean all the warnings, then I send you a patch.
After I send a SIGINT (CTRL+C):
#0 0x00007ffff64367f1 in ppoll (fds=<optimized>, nfds=<optimized>,
#1 0x00007ffff46f1637 in pa_mainloop_poll ()
#2 0x00007ffff46f1c09 in pa_mainloop_iterate ()
#3 0x00007ffff79cdaa4 in pulseaudio_open ()
#4 0x00007ffff79c5ee2 in do_install_audio (mode=<optimized>)
#5 0x00007ffff79c5f5a in do_install_audio (mode=<optimized>)
#6 0x000000000045ec02 in Sound_Init() ()
#7 0x000000000040477c in main ()
||Posted: Sun Oct 30, 2011 10:51 pm|
|Do the Allegro audio samples works for you?|
|Goto page Previous 1, 2, 3, 4, 5 Next|