Previous Thread
Next Thread
Print Thread
Page 113 of 536 1 2 111 112 113 114 115 535 536
Joined: Sep 2009
Posts: 84
M
Member
Offline
Member
M
Joined: Sep 2009
Posts: 84
Hello all i have some errors with last svn 6716:

src/mess/drivers/n64.c:41: error: initializer element is not constant
src/mess/drivers/n64.c:41: error: (near initialization for 'address_map_n64_map[32].i')
src/mess/drivers/n64.c:42: error: initializer element is not constant
src/mess/drivers/n64.c:42: error: (near initialization for 'address_map_n64_map[44].i')
src/mess/drivers/n64.c:58: error: initializer element is not constant
src/mess/drivers/n64.c:58: error: (near initialization for 'address_map_rsp_map[10].i')
src/mess/drivers/n64.c:59: error: initializer element is not constant
src/mess/drivers/n64.c:59: error: (near initialization for 'address_map_rsp_map[20].i')
src/mess/drivers/n64.c:60: error: initializer element is not constant
src/mess/drivers/n64.c:60: error: (near initialization for 'address_map_rsp_map[30].i')
src/mess/drivers/n64.c:61: error: initializer element is not constant
src/mess/drivers/n64.c:61: error: (near initialization for 'address_map_rsp_map[40].i')
mingw32-make: *** [obj/windows/mamep/mess/drivers/n64.o] Error 1

I have tested clean compil but nothin
Someone know where is the problem please?
Thanks

Last edited by Multipass; 12/20/09 11:12 PM.
Joined: Mar 2001
Posts: 16,751
Likes: 29
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,751
Likes: 29
SVN #6716 works for me, and the automated builder passed as well. You're either doing something wrong or building on an exotic configuration - good luck figuring it out smile

Last edited by R. Belmont; 12/21/09 01:09 AM.
Joined: Jul 2007
Posts: 4,625
A
Anna Wu Offline OP
Very Senior Member
OP Offline
Very Senior Member
A
Joined: Jul 2007
Posts: 4,625
SVN r6736
Micronique Hector HRX driver
Game : Pengo (Cassette, .k7)



Thank you for your nice email, Jean-Jacques. smile

Last edited by Anna Wu; 12/25/09 04:38 PM.
Joined: Dec 2006
Posts: 529
M
Senior Member
Offline
Senior Member
M
Joined: Dec 2006
Posts: 529
Happy Boxing Day! (Well, it is past 1:30am here... smile





It's somewhat playable (joystick directions aren't quite right), has no sound effects (but there is CD-DA music), and still some sprite mis-alignment. But eh, it runs. smile


- Barry Rodewald
Joined: Jul 2007
Posts: 4,625
A
Anna Wu Offline OP
Very Senior Member
OP Offline
Very Senior Member
A
Joined: Jul 2007
Posts: 4,625
Originally Posted By mahlemiut
Happy Boxing Day! (Well, it is past 1:30am here... smile

It's somewhat playable (joystick directions aren't quite right), has no sound effects (but there is CD-DA music), and still some sprite mis-alignment. But eh, it runs. smile


Thank you for the info, Barry ! smile
I will test the driver as soon as possible. At moment is my clean compile time.
Except Raiden, any other game (CD or Floppy Disk) can be loaded ?

Joined: Dec 2006
Posts: 529
M
Senior Member
Offline
Senior Member
M
Joined: Dec 2006
Posts: 529
Originally Posted By Anna Wu
I will test the driver as soon as possible. At moment is my clean compile time.
Except Raiden, any other game (CD or Floppy Disk) can be loaded ?

Nope, pretty much limited to real-mode DOS applications. Most FM Towns software requires protected mode. I can't even run simple protected mode test programs that I've written using Towns-GCC (GCC 2.45 cross-compiler, generates protected mode .EXP executables)
Maybe there are other real-mode games out there, but I'm sure most require protected mode.


- Barry Rodewald
Joined: Mar 2001
Posts: 16,751
Likes: 29
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,751
Likes: 29
Can we get a discussion going on the desirability of the "F4 support" patches that Robbbbbert is submitting? I vote "wastes memory and execution time and clutters the drivers for no useful reason", but MESS has never had adult supervision before so I assume they will continue to go in.

In case it's not clear: F4 is a developer aid, not a user feature. It not working for a driver is not considered a problem. Since the drivers the support is being added to all already can decode and display the characters properly there is no developer benefit to them either.

Joined: May 2009
Posts: 1,946
Likes: 13
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,946
Likes: 13
Me, I added a few debugging dips to the CD-i driver so that it would be easier for people to rip graphics from the game, so I don't see a problem with what Robbbert's doing.

While it can be argued that it "clutters up" a driver, you said yourself that the drivers can already decode and display the characters properly, so that implies that the drivers are already largely complete. In the event that they are not, throwing in a few more blocks of code isn't going to harm anything.

While you claim that it's "a developer aid, not a user feature," users already view F4 as a user feature, and you as a MAME dev should know quite well how much official proclamations from devs have an impact on what users think. At this point, I'd say we'd might as well run with it.

About the only suggestion I have, not having seen the code that Robbbert is adding in (the above "few more blocks of code" was an assumption), is that it should be commented as being related to the F4 viewer and not the actual functional emulation of the system.

Joined: May 2004
Posts: 1,670
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,670
Originally Posted By R. Belmont
Can we get a discussion going on the desirability of the "F4 support" patches that Robbbbbert is submitting? I vote "wastes memory and execution time and clutters the drivers for no useful reason", but MESS has never had adult supervision before so I assume they will continue to go in.

In case it's not clear: F4 is a developer aid, not a user feature. It not working for a driver is not considered a problem. Since the drivers the support is being added to all already can decode and display the characters properly there is no developer benefit to them either.


Context.

While I agree, MESS needs more overall quality control you have to look at things in context.

I looked over some of the changes, and they have no performance hit. This is case #1, they're a one time decode, which decode the character stored in the BIOS rom.

Case #2 is dynamic decodes (which decode characters as they're uploaded to RAM) *do* have a cost, especially if they're not needed by the driver, which obviously if they're added as an afterthought aren't.

Of course in case #1 you'll only ever get the same decode every time you run the driver. The characters never change, they're the bios characters, they're not very interesting*

In case #2, the characters will change. If you're developing a driver, this might be useful to indicate how far a specific game has gone towards loading, has it ever uploaded gfx data, or did it get stuck before that point? It can be considered a useful dev aid, if the developers of that driver need it.

As with MAME, there are 2 groups of users. Developers using the code, to make improvements, and end-users, just using it to play games. Benefits to the first group can be very important, benefits to the 2nd group, a little less-so. You could argue that having F4 available (on dynamic drivers) benefits the developers (seeing what's uploaded) but puts players at a disdavantage (slower speed).

For changes like this that's what is important, you need to weigh up the cost / benefit, in some cases they're useless, in other cases not so much. The ones checked in so far are harmless, but ultimately not very interesting. They add no value, but they have no cost aside a few lines of easily understandable code.


* For console / computer systems where they'll likely only contain the BIOS font, obviously MAME is different where most of the game GFX are usually in static ROM.

Joined: May 2009
Posts: 1,946
Likes: 13
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,946
Likes: 13
With the latest SVN tree, there should be a number of considerable N64 optimizations, including a muchly-improved RSP DRC and more RDP flattening. The following caveats should be noted:

1) There is an as-yet unknown bug affecting texel lookups for certain texture types, as exhibited in Tetrisphere.
2) I have temporarily disabled vi_filter16 and divot_filter16, because there are a few fiddly things about them I don't trust. This has given a temporary speed boost, but expect a slight drop in performance once they come back online.

Page 113 of 536 1 2 111 112 113 114 115 535 536

Link Copied to Clipboard
Who's Online Now
1 members (1 invisible), 31 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,940
Posts117,525
Members4,994
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com