Previous Thread
Next Thread
Print Thread
Page 113 of 528 1 2 111 112 113 114 115 527 528
Re: SVN builds - new driver flood [Re: Just Desserts] #57241 12/20/09 11:10 PM
Joined: Sep 2009
Posts: 84
M
Multipass Offline
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.
Re: SVN builds - new driver flood [Re: Multipass] #57242 12/21/09 01:08 AM
Joined: Mar 2001
Posts: 16,335
R
R. Belmont Online Content
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,335
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.
Re: SVN builds - new driver flood [Re: Anna Wu] #57301 12/25/09 10:53 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.
Re: SVN builds - new driver flood [Re: Anna Wu] #57302 12/25/09 12:39 PM
Joined: Dec 2006
Posts: 526
M
mahlemiut Offline
Senior Member
Offline
Senior Member
M
Joined: Dec 2006
Posts: 526
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
Re: SVN builds - new driver flood [Re: mahlemiut] #57304 12/25/09 04:42 PM
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 ?

Re: SVN builds - new driver flood [Re: Anna Wu] #57309 12/25/09 08:44 PM
Joined: Dec 2006
Posts: 526
M
mahlemiut Offline
Senior Member
Offline
Senior Member
M
Joined: Dec 2006
Posts: 526
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
Re: SVN builds - new driver flood [Re: mahlemiut] #57313 12/26/09 04:02 AM
Joined: Mar 2001
Posts: 16,335
R
R. Belmont Online Content
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,335
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.

Re: SVN builds - new driver flood [Re: R. Belmont] #57322 12/26/09 04:19 PM
Joined: May 2009
Posts: 1,806
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,806
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.

Re: SVN builds - new driver flood [Re: R. Belmont] #57323 12/26/09 05:16 PM
Joined: May 2004
Posts: 1,598
H
Haze Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,598
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.

Re: SVN builds - new driver flood [Re: Haze] #57359 12/28/09 06:38 AM
Joined: May 2009
Posts: 1,806
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,806
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 528 1 2 111 112 113 114 115 527 528

Who's Online Now
4 registered members (Kale, R. Belmont, Pernod, zino), 125 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,692
Posts114,252
Members4,865
Most Online510
Aug 26th, 2019
Powered by UBB.threads™ PHP Forum Software 7.7.3