From bugs at real-time.com Tue Jul 4 19:39:26 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] [Bug 33] New - Client 'You see:' list position gets reset to 0 unexpectedly Message-ID: <200007050039.e650dQn25078@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=33 *** shadow/33 Tue Jul 4 19:39:26 2000 --- shadow/33.tmp.25075 Tue Jul 4 19:39:26 2000 *************** *** 0 **** --- 1,43 ---- + Bug#: 33 + Product: Crossfire + Version: 0.95.6 + Platform: PC + OS/Version: other + Status: NEW + Resolution: + Severity: normal + Priority: P3 + Component: X11 Client + AssignedTo: crossfire-devel@lists.real-time.com + ReportedBy: frank_mckenney@mindspring.com + URL: + Cc: + Summary: Client 'You see:' list position gets reset to 0 unexpectedly + + X11 client + + If there are more items on the player's square than can be shown in the + 'You see:' window and if the list has been scrolled so that the topmost + visible item is not the first item in the list, picking up an item may + cause the list view to "reset" itstelf so that the topmost item shown + _is_ the first item in the list. + + This extremely annoying behavior can be seen when trying to pick out + (e.g.) non-cursed items from a post-battle pile of assorted weapons and + armor. It can also be seen when opening a stack of (hopefully + de-trapped (;-)) chests. + + At one point it appeared that this problem was related to the presence + of "animated" icons in hte list (e.g. gems), but the evidence is a + litle muddy. + + In terms of the client code, this seems to happen when + x11.c/draw_list(l) is called and: + + l == look_list + l->env is non-NULL + l->env->inv is NULL + + Since there appear to be no items in the list, draw_list() forces the + look_list->item_pos to 0, so on the next pass through draw_list(), when + l->env->inv is non-NULL, the list is drawn from its first item. From bugs at real-time.com Wed Jul 5 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007050710.e657A2s26172@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 From bugs at real-time.com Wed Jul 5 10:33:27 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] [Bug 34] New - Can't stop running until obstacle hit Message-ID: <200007051533.e65FXRc29016@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=34 *** shadow/34 Wed Jul 5 10:33:27 2000 --- shadow/34.tmp.29013 Wed Jul 5 10:33:27 2000 *************** *** 0 **** --- 1,85 ---- + Bug#: 34 + Product: Crossfire + Version: 0.95.6 + Platform: PC + OS/Version: Linux + Status: NEW + Resolution: + Severity: normal + Priority: P3 + Component: X11 Client + AssignedTo: crossfire-devel@lists.real-time.com + ReportedBy: frank_mckenney@mindspring.com + URL: + Cc: + Summary: Can't stop running until obstacle hit + + Server: 0.95.6 public release + Intel x86 PC, 486DX4-100, 32 Mb RAM, SuSE Linux 6.4 + Client: 0.95.6 public release (X11 client) + (same machine) + + Also occurs on CVS 2000/07/04 + + The "Run" key (Ctl on Linux X11 client) is an extremely useful feature. + It provides much more responsive control over movement than (e.g.) + building up a huge "stack" of comands by holding down the "east" key + "for a while" (;-). + + Normally, movement controled by the Run key will halt as soon as the Run + key is released. However, in CF 0.95.6 under certain circumstances it + may be difficult or impossible to stop until an obstacle is hit. + + An example: after starting the Linux X11 client and logging my + character in to the server, I left the Permanent Apartments in Scorn and + single-stepped at a leisurely pace over to westernmost signpost + ("Welcome to Crossfire"). I then held down Ctl key and pressed + right-arrow key ("east") briefly. + + "Run On" appeared in status window, and did not disappear until I had + run over to eastern gatehouse, the inner gate had opened, and I had run + all the way to the outer gate. Pressing and releasing the Ctl key had + no effect - my character just kept running. + + Frequently, on leaving Scorn by the East Gate, if I do a _brief_ + Ctl-"east" as soon as I am past the outer gate, I will start running and + not stop until I hit some spot in the mountains (map boundary?). + + In all cases, once movement has started, nothing seems to stop it until + some obstacle is encountered. + + This seems to happen more frequently just after entering a map, but (as + in my example) some "normal" single-step movement may take place in that + map first. It can also occur some time after a map has been entered. + + Speculation: The "run_stop" command does not seem to have gotten + _lost_, merely delayed, since I don't wind up with my poor character + permanently beating his head against a wall (although it is a good thing + that the guard in the inner gate has a very forgiving nature). + + Also, I usually notice this problem when my character is moving into a + part of a map where it has never been, or has not yet traversed or + seen on the current visit to the current map. + + I'm not familiar with the way the server updates the client's map, but + if it is done as-needed rather than on an everything-at-entry-to-map + basis, and if a "run_stop" is _not_ given precedence over either of + + a) Movement, or + b) The transfer of map information, + + then we have a nasty situation. The character "runs" into unvisited + territory, and continues to move as the server refreshes that portion of + the map. But the character continues moving into yet-newer territory, + requiring further map refresh... until the character finally runs into + something that stops it long enough for everything to catch up. + + Whatever the actual cause, the root problem is the same: the + character's movement cycle is never interrupted by the "run_stop" + command the client is (presumably) sending. + + Severity: If you're not aware of it, this one can drastically shorten + one's current incarnation; Crossfire is not a game that takes kindly to + repeated assaults on random characters (the gate guard is a notable + exception (;-)). However, with some caution, this one can be lived + with/mostly avoided. From bugs at real-time.com Thu Jul 6 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007060710.e667A1i11980@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 From bugs at real-time.com Fri Jul 7 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007070710.e677A1220818@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 From bugs at real-time.com Sat Jul 8 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:23 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007080710.e687A2X29283@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 From bugs at real-time.com Sun Jul 9 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007090710.e697A1C04637@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 From bugs at real-time.com Mon Jul 10 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007100710.e6A7A2m19036@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 From bugs at real-time.com Tue Jul 11 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007110710.e6B7A2F28346@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 From bugs at real-time.com Wed Jul 12 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007120710.e6C7A2l05496@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 From bugs at real-time.com Wed Jul 12 14:26:55 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] [Bug 47] New - World Map linkage errors (lost-at-sea HOWTO) Message-ID: <200007121926.e6CJQt510323@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=47 *** shadow/47 Wed Jul 12 14:26:55 2000 --- shadow/47.tmp.10320 Wed Jul 12 14:26:55 2000 *************** *** 0 **** --- 1,46 ---- + Bug#: 47 + Product: Crossfire + Version: 0.95.6 + Platform: All + OS/Version: All + Status: NEW + Resolution: + Severity: normal + Priority: P3 + Component: maps + AssignedTo: crossfire-devel@lists.real-time.com + ReportedBy: frank_mckenney@mindspring.com + URL: + Cc: + Summary: World Map linkage errors (lost-at-sea HOWTO) + + The maps shipped with Crossfire 0.95.6 have at least two linkage errors. + One is nasty, but hard to hit, and the second, while easier to run into, + appears to be only a minor irritation. + + Lost At Sea + + Warning: Do not try this unless your character knows "word of recall" + or you have a "word of recall" scroll. + + Exit Navar to the countryside, and position your character in the SW of + the four squares representing Navar. From here, go 2SW, 1S, and then + 1N. You will notice a change in your environment: You're on map + world_c2 at 20,5, a spot that's usually hard to get to, and there's + "nothing" north of you. + + Now don your bathing trunks and go 5S. You appear to be completely + lost, but (as you quickly determine from the 'mapinfo command) you are + actually on map world_c1 at 20,0, and from that square there _is_ no + land in sight. + + Countryside "hiccups" + + Warning: I did not encounter any serious problems playing around in + this generally inaccessible map section, but that doesn't + mean there's nothing nasty there. + + From the sign 1W from the N-S section of the Great Scorn-Navar Highway, + go 8E, then move 1N. The countryside will undergo some "odd" + transitions, but if you move far enough W, S, or E, things will clear + up. From bugs at real-time.com Wed Jul 12 20:34:21 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] [Bug 47] Changed - World Map linkage errors (lost-at-sea HOWTO) Message-ID: <200007130134.e6D1YLO12624@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=47 *** shadow/47 Wed Jul 12 14:26:55 2000 --- shadow/47.tmp.12621 Wed Jul 12 20:34:21 2000 *************** *** 8,14 **** Severity: normal Priority: P3 Component: maps ! AssignedTo: crossfire-devel@lists.real-time.com ReportedBy: frank_mckenney@mindspring.com URL: Cc: --- 8,14 ---- Severity: normal Priority: P3 Component: maps ! AssignedTo: john_cater@yahoo.com ReportedBy: frank_mckenney@mindspring.com URL: Cc: From mwedel at scruznet.com Wed Jul 12 20:57:44 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] CVS update: maps/world Message-ID: <200007130157.SAA03218@boltzmann.EECS.Berkeley.EDU> Date: Wednesday July 12, 2000 @ 18:57 Author: cater Update of /home/cvs/CVS/maps/world In directory boltzmann:/tmp/cvs-serv3214/world Modified Files: world_b3 world_c2 Log Message: **************************************** Index: maps/world/world_b3 diff -u maps/world/world_b3:1.2 maps/world/world_b3:1.3 --- maps/world/world_b3:1.2 Fri Jun 9 01:52:08 2000 +++ maps/world/world_b3 Wed Jul 12 18:57:44 2000 @@ -3099,6 +3099,7 @@ arch exit slaying world_b2 hp 20 +sp 28 x 20 y 5 end @@ -5222,7 +5223,6 @@ monsterstyle dragon final_map /peterm/quests/dragonquest2 dungeon_depth 12 - endmsg x 34 y 6 Index: maps/world/world_c2 diff -u maps/world/world_c2:1.1 maps/world/world_c2:1.2 --- maps/world/world_c2:1.1 Sun Mar 28 19:48:14 1999 +++ maps/world/world_c2 Wed Jul 12 18:57:44 2000 @@ -1,4 +1,5 @@ arch map +name world_c2 msg Creator: Skud the Great Email: tvangod@ecst.csuchico.edu @@ -3100,6 +3101,7 @@ arch exit slaying world_c1 hp 20 +sp 28 x 20 y 5 end From mwedel at scruznet.com Wed Jul 12 20:57:44 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] CVS update: maps Message-ID: <200007130157.SAA03224@boltzmann.EECS.Berkeley.EDU> Date: Wednesday July 12, 2000 @ 18:57 Author: cater Update of /home/cvs/CVS/maps In directory boltzmann:/tmp/cvs-serv3214 Modified Files: CHANGES Log Message: **************************************** Index: maps/CHANGES diff -u maps/CHANGES:1.17 maps/CHANGES:1.18 --- maps/CHANGES:1.17 Tue Jun 20 21:31:15 2000 +++ maps/CHANGES Wed Jul 12 18:57:44 2000 @@ -1,5 +1,8 @@ Changes for CVS tree: +world/world_b3 world/world_c2 +Changes made to slaying field of exits to stop characters being "stranded" at sea +- John Cater 7/13/2000 ------------------------------------------------------------------------------ Crossfire-maps-0.95.6 released. From bugs at real-time.com Thu Jul 13 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007130710.e6D7A2u14414@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Fri Jul 14 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007140710.e6E7A2822757@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Sat Jul 15 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007150710.e6F7A2230869@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Sun Jul 16 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007160710.e6G7A2005247@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Mon Jul 17 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007170710.e6H7A1P23091@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From peterm at tesla.EECS.Berkeley.EDU Mon Jul 17 23:22:26 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Purify and crossfire? Message-ID: <200007180422.VAA14261@tesla.EECS.Berkeley.EDU> Does anyone have access to Purify to run Crossfire under it? That might help a lot in finding some of the problems which (admittedly decreasingly thanks to lots of recent bugfixes) continue to plague crossfire. I had a go at using Electric Fence on crossfire recently, without much result. PeterM From bugs at real-time.com Tue Jul 18 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007180710.e6I7A2b11154@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From echter at informatik.uni-rostock.de Tue Jul 18 09:10:43 2000 From: echter at informatik.uni-rostock.de (Jan Echternach) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Purify and crossfire? In-Reply-To: <200007180422.VAA14261@tesla.EECS.Berkeley.EDU>; from peterm@tesla.EECS.Berkeley.EDU on Mon, Jul 17, 2000 at 09:22:26PM -0700 References: <200007180422.VAA14261@tesla.EECS.Berkeley.EDU> Message-ID: <20000718161043.A9398@hokkaido.informatik.uni-rostock.de> On Mon, Jul 17, 2000 at 09:22:26PM -0700, Peter Mardahl wrote: > That might help a lot in finding some of the problems which > (admittedly decreasingly thanks to lots of recent bugfixes) > continue to plague crossfire. If you're refering to problems like "trying to remove removed object" and "found freed object": server/monster.c urgently needs a review for missing was_destroyed() checks. Changes in the last version added handling for several object types to move_apply(), which means that it is now more likely for these bugs to get triggered (monster steps on trap or spell, gets killed, but move_monster() doesn't notice this and continues with a freed object). -- Jan From peterm at tesla.EECS.Berkeley.EDU Tue Jul 18 18:41:15 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Change in the CVS server for crossfire Message-ID: <200007182341.QAA16891@tesla.EECS.Berkeley.EDU> The old "boltzmann" has been upgraded to a dual 400MHz PII machine as of today. I made an effort to make the new machine operate identically to the old one as our CVS repository server. Please let me know of any difficulty. NOTE: you will have to change your host key: you WILL get a message about a change. PeterM From bugs at real-time.com Wed Jul 19 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007190710.e6J7A1p31981@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From mwedel at scruznet.com Wed Jul 19 22:56:28 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] CVS update: crossfire/server Message-ID: <200007200356.UAA07899@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/server In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/server Modified Files: resurrection.c Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/server/resurrection.c diff -u crossfire/server/resurrection.c:1.3 crossfire/server/resurrection.c:1.4 --- crossfire/server/resurrection.c:1.3 Fri May 26 02:50:49 2000 +++ crossfire/server/resurrection.c Wed Jul 19 20:56:28 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_resurrection_c = - * "$Id: resurrection.c,v 1.3 2000/05/26 09:50:49 jec Exp $"; + * "$Id: resurrection.c,v 1.4 2000/07/20 03:56:28 peterm Exp $"; */ /* @@ -227,13 +227,13 @@ sscanf(buf,"%s %ld",buf2,&exp); switch(rspell) { case SP_RAISE_DEAD: - exp-=exp/20; + exp-=exp/5; break; case SP_RESURRECTION: exp-=exp/10; break; case SP_REINCARNATION: - exp-=exp/5; + exp-=exp/20; break; } sprintf(buf,"exp %ld\n",exp); From mwedel at scruznet.com Wed Jul 19 22:56:27 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:24 2005 Subject: [CF-Devel] CVS update: crossfire/include Message-ID: <200007200356.UAA07894@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/include In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/include Modified Files: spellist.h Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/include/spellist.h diff -u crossfire/include/spellist.h:1.7 crossfire/include/spellist.h:1.8 --- crossfire/include/spellist.h:1.7 Sun Jun 4 16:23:50 2000 +++ crossfire/include/spellist.h Wed Jul 19 20:56:27 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_spellist_h = - * "$Id: spellist.h,v 1.7 2000/06/04 23:23:50 cvs Exp $"; + * "$Id: spellist.h,v 1.8 2000/07/20 03:56:27 peterm Exp $"; */ /* @@ -214,11 +214,11 @@ PATH_MISSILE, NULL,}, /* 90 */ {"mystic fist", 5,10, 0, 15, 0, 0, 1, 1, 0, 0, 0, PATH_SUMMON, "mystic_fist",}, -{"raise dead", 10,50, 0, 60, 0, 0, 0, 1, 0, 1, 0, +{"raise dead", 10,150, 0, 60, 0, 0, 0, 1, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"resurrection", 25,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, +{"resurrection", 20,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"reincarnation", 20,150, 0,100, 0, 0, 0, 0, 0, 1, 0, +{"reincarnation", 25,350, 0,100, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, /* mlee - Keep these spells 0 book chance, as they are low level quest items.*/ /* raised the grace value on some immuntity spells -b.t. */ From mwedel at scruznet.com Wed Jul 19 22:56:28 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/server Message-ID: <200007200356.UAA07899@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/server In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/server Modified Files: resurrection.c Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/server/resurrection.c diff -u crossfire/server/resurrection.c:1.3 crossfire/server/resurrection.c:1.4 --- crossfire/server/resurrection.c:1.3 Fri May 26 02:50:49 2000 +++ crossfire/server/resurrection.c Wed Jul 19 20:56:28 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_resurrection_c = - * "$Id: resurrection.c,v 1.3 2000/05/26 09:50:49 jec Exp $"; + * "$Id: resurrection.c,v 1.4 2000/07/20 03:56:28 peterm Exp $"; */ /* @@ -227,13 +227,13 @@ sscanf(buf,"%s %ld",buf2,&exp); switch(rspell) { case SP_RAISE_DEAD: - exp-=exp/20; + exp-=exp/5; break; case SP_RESURRECTION: exp-=exp/10; break; case SP_REINCARNATION: - exp-=exp/5; + exp-=exp/20; break; } sprintf(buf,"exp %ld\n",exp); From mwedel at scruznet.com Wed Jul 19 22:56:27 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/include Message-ID: <200007200356.UAA07894@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/include In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/include Modified Files: spellist.h Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/include/spellist.h diff -u crossfire/include/spellist.h:1.7 crossfire/include/spellist.h:1.8 --- crossfire/include/spellist.h:1.7 Sun Jun 4 16:23:50 2000 +++ crossfire/include/spellist.h Wed Jul 19 20:56:27 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_spellist_h = - * "$Id: spellist.h,v 1.7 2000/06/04 23:23:50 cvs Exp $"; + * "$Id: spellist.h,v 1.8 2000/07/20 03:56:27 peterm Exp $"; */ /* @@ -214,11 +214,11 @@ PATH_MISSILE, NULL,}, /* 90 */ {"mystic fist", 5,10, 0, 15, 0, 0, 1, 1, 0, 0, 0, PATH_SUMMON, "mystic_fist",}, -{"raise dead", 10,50, 0, 60, 0, 0, 0, 1, 0, 1, 0, +{"raise dead", 10,150, 0, 60, 0, 0, 0, 1, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"resurrection", 25,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, +{"resurrection", 20,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"reincarnation", 20,150, 0,100, 0, 0, 0, 0, 0, 1, 0, +{"reincarnation", 25,350, 0,100, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, /* mlee - Keep these spells 0 book chance, as they are low level quest items.*/ /* raised the grace value on some immuntity spells -b.t. */ From mwedel at scruznet.com Wed Jul 19 22:56:28 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/server Message-ID: <200007200356.UAA07899@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/server In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/server Modified Files: resurrection.c Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/server/resurrection.c diff -u crossfire/server/resurrection.c:1.3 crossfire/server/resurrection.c:1.4 --- crossfire/server/resurrection.c:1.3 Fri May 26 02:50:49 2000 +++ crossfire/server/resurrection.c Wed Jul 19 20:56:28 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_resurrection_c = - * "$Id: resurrection.c,v 1.3 2000/05/26 09:50:49 jec Exp $"; + * "$Id: resurrection.c,v 1.4 2000/07/20 03:56:28 peterm Exp $"; */ /* @@ -227,13 +227,13 @@ sscanf(buf,"%s %ld",buf2,&exp); switch(rspell) { case SP_RAISE_DEAD: - exp-=exp/20; + exp-=exp/5; break; case SP_RESURRECTION: exp-=exp/10; break; case SP_REINCARNATION: - exp-=exp/5; + exp-=exp/20; break; } sprintf(buf,"exp %ld\n",exp); From mwedel at scruznet.com Wed Jul 19 22:56:27 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/include Message-ID: <200007200356.UAA07894@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/include In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/include Modified Files: spellist.h Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/include/spellist.h diff -u crossfire/include/spellist.h:1.7 crossfire/include/spellist.h:1.8 --- crossfire/include/spellist.h:1.7 Sun Jun 4 16:23:50 2000 +++ crossfire/include/spellist.h Wed Jul 19 20:56:27 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_spellist_h = - * "$Id: spellist.h,v 1.7 2000/06/04 23:23:50 cvs Exp $"; + * "$Id: spellist.h,v 1.8 2000/07/20 03:56:27 peterm Exp $"; */ /* @@ -214,11 +214,11 @@ PATH_MISSILE, NULL,}, /* 90 */ {"mystic fist", 5,10, 0, 15, 0, 0, 1, 1, 0, 0, 0, PATH_SUMMON, "mystic_fist",}, -{"raise dead", 10,50, 0, 60, 0, 0, 0, 1, 0, 1, 0, +{"raise dead", 10,150, 0, 60, 0, 0, 0, 1, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"resurrection", 25,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, +{"resurrection", 20,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"reincarnation", 20,150, 0,100, 0, 0, 0, 0, 0, 1, 0, +{"reincarnation", 25,350, 0,100, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, /* mlee - Keep these spells 0 book chance, as they are low level quest items.*/ /* raised the grace value on some immuntity spells -b.t. */ From mwedel at scruznet.com Wed Jul 19 22:56:28 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/server Message-ID: <200007200356.UAA07899@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/server In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/server Modified Files: resurrection.c Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/server/resurrection.c diff -u crossfire/server/resurrection.c:1.3 crossfire/server/resurrection.c:1.4 --- crossfire/server/resurrection.c:1.3 Fri May 26 02:50:49 2000 +++ crossfire/server/resurrection.c Wed Jul 19 20:56:28 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_resurrection_c = - * "$Id: resurrection.c,v 1.3 2000/05/26 09:50:49 jec Exp $"; + * "$Id: resurrection.c,v 1.4 2000/07/20 03:56:28 peterm Exp $"; */ /* @@ -227,13 +227,13 @@ sscanf(buf,"%s %ld",buf2,&exp); switch(rspell) { case SP_RAISE_DEAD: - exp-=exp/20; + exp-=exp/5; break; case SP_RESURRECTION: exp-=exp/10; break; case SP_REINCARNATION: - exp-=exp/5; + exp-=exp/20; break; } sprintf(buf,"exp %ld\n",exp); From mwedel at scruznet.com Wed Jul 19 22:56:27 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/include Message-ID: <200007200356.UAA07894@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/include In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/include Modified Files: spellist.h Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/include/spellist.h diff -u crossfire/include/spellist.h:1.7 crossfire/include/spellist.h:1.8 --- crossfire/include/spellist.h:1.7 Sun Jun 4 16:23:50 2000 +++ crossfire/include/spellist.h Wed Jul 19 20:56:27 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_spellist_h = - * "$Id: spellist.h,v 1.7 2000/06/04 23:23:50 cvs Exp $"; + * "$Id: spellist.h,v 1.8 2000/07/20 03:56:27 peterm Exp $"; */ /* @@ -214,11 +214,11 @@ PATH_MISSILE, NULL,}, /* 90 */ {"mystic fist", 5,10, 0, 15, 0, 0, 1, 1, 0, 0, 0, PATH_SUMMON, "mystic_fist",}, -{"raise dead", 10,50, 0, 60, 0, 0, 0, 1, 0, 1, 0, +{"raise dead", 10,150, 0, 60, 0, 0, 0, 1, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"resurrection", 25,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, +{"resurrection", 20,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"reincarnation", 20,150, 0,100, 0, 0, 0, 0, 0, 1, 0, +{"reincarnation", 25,350, 0,100, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, /* mlee - Keep these spells 0 book chance, as they are low level quest items.*/ /* raised the grace value on some immuntity spells -b.t. */ From mwedel at scruznet.com Wed Jul 19 22:56:28 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/server Message-ID: <200007200356.UAA07899@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/server In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/server Modified Files: resurrection.c Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/server/resurrection.c diff -u crossfire/server/resurrection.c:1.3 crossfire/server/resurrection.c:1.4 --- crossfire/server/resurrection.c:1.3 Fri May 26 02:50:49 2000 +++ crossfire/server/resurrection.c Wed Jul 19 20:56:28 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_resurrection_c = - * "$Id: resurrection.c,v 1.3 2000/05/26 09:50:49 jec Exp $"; + * "$Id: resurrection.c,v 1.4 2000/07/20 03:56:28 peterm Exp $"; */ /* @@ -227,13 +227,13 @@ sscanf(buf,"%s %ld",buf2,&exp); switch(rspell) { case SP_RAISE_DEAD: - exp-=exp/20; + exp-=exp/5; break; case SP_RESURRECTION: exp-=exp/10; break; case SP_REINCARNATION: - exp-=exp/5; + exp-=exp/20; break; } sprintf(buf,"exp %ld\n",exp); From mwedel at scruznet.com Wed Jul 19 22:56:27 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/include Message-ID: <200007200356.UAA07894@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/include In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/include Modified Files: spellist.h Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/include/spellist.h diff -u crossfire/include/spellist.h:1.7 crossfire/include/spellist.h:1.8 --- crossfire/include/spellist.h:1.7 Sun Jun 4 16:23:50 2000 +++ crossfire/include/spellist.h Wed Jul 19 20:56:27 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_spellist_h = - * "$Id: spellist.h,v 1.7 2000/06/04 23:23:50 cvs Exp $"; + * "$Id: spellist.h,v 1.8 2000/07/20 03:56:27 peterm Exp $"; */ /* @@ -214,11 +214,11 @@ PATH_MISSILE, NULL,}, /* 90 */ {"mystic fist", 5,10, 0, 15, 0, 0, 1, 1, 0, 0, 0, PATH_SUMMON, "mystic_fist",}, -{"raise dead", 10,50, 0, 60, 0, 0, 0, 1, 0, 1, 0, +{"raise dead", 10,150, 0, 60, 0, 0, 0, 1, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"resurrection", 25,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, +{"resurrection", 20,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"reincarnation", 20,150, 0,100, 0, 0, 0, 0, 0, 1, 0, +{"reincarnation", 25,350, 0,100, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, /* mlee - Keep these spells 0 book chance, as they are low level quest items.*/ /* raised the grace value on some immuntity spells -b.t. */ From mwedel at scruznet.com Wed Jul 19 22:56:28 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/server Message-ID: <200007200356.UAA07899@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/server In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/server Modified Files: resurrection.c Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/server/resurrection.c diff -u crossfire/server/resurrection.c:1.3 crossfire/server/resurrection.c:1.4 --- crossfire/server/resurrection.c:1.3 Fri May 26 02:50:49 2000 +++ crossfire/server/resurrection.c Wed Jul 19 20:56:28 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_resurrection_c = - * "$Id: resurrection.c,v 1.3 2000/05/26 09:50:49 jec Exp $"; + * "$Id: resurrection.c,v 1.4 2000/07/20 03:56:28 peterm Exp $"; */ /* @@ -227,13 +227,13 @@ sscanf(buf,"%s %ld",buf2,&exp); switch(rspell) { case SP_RAISE_DEAD: - exp-=exp/20; + exp-=exp/5; break; case SP_RESURRECTION: exp-=exp/10; break; case SP_REINCARNATION: - exp-=exp/5; + exp-=exp/20; break; } sprintf(buf,"exp %ld\n",exp); From mwedel at scruznet.com Wed Jul 19 22:56:27 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire/include Message-ID: <200007200356.UAA07894@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 20:56 Author: peterm Update of /home/cvs/CVS/crossfire/include In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv7890/include Modified Files: spellist.h Log Message: Some minor corrections of unintended stuff in resurrection code. **************************************** Index: crossfire/include/spellist.h diff -u crossfire/include/spellist.h:1.7 crossfire/include/spellist.h:1.8 --- crossfire/include/spellist.h:1.7 Sun Jun 4 16:23:50 2000 +++ crossfire/include/spellist.h Wed Jul 19 20:56:27 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_spellist_h = - * "$Id: spellist.h,v 1.7 2000/06/04 23:23:50 cvs Exp $"; + * "$Id: spellist.h,v 1.8 2000/07/20 03:56:27 peterm Exp $"; */ /* @@ -214,11 +214,11 @@ PATH_MISSILE, NULL,}, /* 90 */ {"mystic fist", 5,10, 0, 15, 0, 0, 1, 1, 0, 0, 0, PATH_SUMMON, "mystic_fist",}, -{"raise dead", 10,50, 0, 60, 0, 0, 0, 1, 0, 1, 0, +{"raise dead", 10,150, 0, 60, 0, 0, 0, 1, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"resurrection", 25,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, +{"resurrection", 20,250, 0, 180, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, -{"reincarnation", 20,150, 0,100, 0, 0, 0, 0, 0, 1, 0, +{"reincarnation", 25,350, 0,100, 0, 0, 0, 0, 0, 1, 0, PATH_RESTORE, "enchantment",}, /* mlee - Keep these spells 0 book chance, as they are low level quest items.*/ /* raised the grace value on some immuntity spells -b.t. */ From mwedel at scruznet.com Thu Jul 20 01:45:48 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: crossfire Message-ID: <200007200645.XAA08860@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 23:45 Author: peterm Update of /home/cvs/CVS/crossfire In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv8852 Modified Files: CHANGES Log Message: Resureection spells changed. **************************************** Index: crossfire/CHANGES diff -u crossfire/CHANGES:1.112 crossfire/CHANGES:1.113 --- crossfire/CHANGES:1.112 Tue Jun 27 23:19:19 2000 +++ crossfire/CHANGES Wed Jul 19 23:45:48 2000 @@ -16,6 +16,10 @@ small - this just lets others know that the file has changed if nothing else. With this, include the file(s) that you changed. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +server/resurrection.c +include/spellist.h: PeterM: fixed a few unintended things about +resurrection: experience removal was wrong, spellpoints/levels +changed. --PetrM lib/archetypes: Update to keep in sync with arch tree. Changes to about a dozen arch's to remove the 'a' in their name. MSW 6/27/2000 From mwedel at scruznet.com Thu Jul 20 01:49:32 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] CVS update: client Message-ID: <200007200649.XAA08916@boltzmann.eecs.berkeley.edu> Date: Wednesday July 19, 2000 @ 23:49 Author: cvs Update of /home/cvs/CVS/client In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv8912 Modified Files: item_types item_types.h player.c Log Message: item_types, item_types.h: Update with new item types - MSW 7/19/2000 player.c: Comment out command buffering output - MSW 7/19/2000 **************************************** Index: client/item_types diff -u client/item_types:1.2 client/item_types:1.3 --- client/item_types:1.2 Sat Apr 22 00:08:55 2000 +++ client/item_types Wed Jul 19 23:49:32 2000 @@ -13,6 +13,9 @@ # is better to put them at a later number so more specific matches will # happen first. # +# While this has not been done for all categories, please try to order +# the entries for each category (number) in alphabetical order. +# # containers # Moved containers to the top - this is because of stuff like quiver of # arrows, but also more convenient @@ -27,25 +30,34 @@ key ring # Weapon types 2: -sword -mace -hammer -Dragonslayer +axe +club +dagger +Darkblade Demonslayer -Trident +Dragonslayer +falchion Flame Tongue +FlameTongue +hammer +katana Lightning sticks -Stormbringer -dagger -quarterstaff -club -axe +mace magnifying glass -spear morningstar -taifu -scimitar +Mournblade +nunchacu +quarterstaff sabre +scimitar +shovel +spear +stake +sword +Stormbringer +taifu +Trident +trident 3: bow crossbow @@ -59,8 +71,12 @@ leather robe shirt +apron +# Headware 11: helmet +Crown +crown 12: shield 13: @@ -76,27 +92,34 @@ bracer # food 20: -food -waybread -roast bird -water +apple booze +bread cabbage +cake carrot chocolate clover -mint sprig -bread -cake +cup +egg fish -steak -apple +food +mint sprig +mushroom +onion +orange potato +roast bird +steak +waybread +water +# gems 30: -ruby diamond -pearl emerald +gold nugget +pearl +ruby sapphire 31: coin @@ -112,45 +135,67 @@ 53: amulet 54: -ring -a ring +ring +Ring 55: scroll +# Spellbooks 56: grimore -treatise +grimoire +hymnal manual -tome +prayerbook +sacred text spellbook +testiment +treatise +tome +# Readables. Note we included the generic book here. 57: -lab book -guidebook -notebook +book +catalog +codex +collection +compendium +compilation +divine work +encyclopedia +exposition +file formulary -tables -recipe book -pamphlet -lab notes -handbook guide -cookbook +holy book +holy record +index +moral text +notes +note +pamphlet +record +tables +transcript +volume 59: potion +bottle 61: balm dust +figurine # Item building scrolls 63: Improve Lower Weapon Enchant Weapon Prepare Weapon -Enchant Armor +Enchant Armour # Misc skill objects 65: +holy symbol +lockpick talisman writing pen -lockpick 67: key Key @@ -158,24 +203,36 @@ # body parts # 70: -pixie dust +arm claw -ectoplasm corpse -wing -residue -lich dust +dragon scale +ectoplasm +eye +foot +hand +head heart +icor +leg +lich dust liver orc chop +pixie dust +residue +skin stinger -beholdereye -head -hand -foot +tongue +tooth +wing # Misc alchemy items (minerals) 71: dirt +lead +mandrake root +pile +rock +stone # 80: flint and steel @@ -184,6 +241,12 @@ # Misc stuff - just to prevent error messages # 90: -icecube +clock +flower +Gate Pass Glowing Crystal +gravestone +icecube library card +Port Pass +rose Index: client/item_types.h diff -u client/item_types.h:1.2 client/item_types.h:1.3 --- client/item_types.h:1.2 Sat Apr 22 00:08:55 2000 +++ client/item_types.h Wed Jul 19 23:49:32 2000 @@ -8,7 +8,7 @@ static char *item_types[256][64] = { { NULL }, { "sack", "Luggage", "pouch", "quiver", "bag", "chest", "key ring", NULL }, -{ "sword", "mace", "hammer", "Dragonslayer", "Demonslayer", "Trident", "Flame Tongue", "Lightning sticks", "Stormbringer", "dagger", "quarterstaff", "club", "axe", "magnifying glass", "spear", "morningstar", "taifu", "scimitar", "sabre", NULL }, +{ "axe", "club", "dagger", "Darkblade", "Demonslayer", "Dragonslayer", "falchion", "Flame Tongue", "FlameTongue", "hammer", "katana", "Lightning sticks", "mace", "magnifying glass", "morningstar", "Mournblade", "nunchacu", "quarterstaff", "sabre", "scimitar", "shovel", "spear", "stake", "sword", "Stormbringer", "taifu", "Trident", "trident", NULL }, { "bow", "crossbow", "sling", "arrow", "bolt", "boulder", NULL }, { NULL }, { NULL }, @@ -16,8 +16,8 @@ { NULL }, { NULL }, { NULL }, -{ "mail", "leather", "robe", "shirt", NULL }, -{ "helmet", NULL }, +{ "mail", "leather", "robe", "shirt", "apron", NULL }, +{ "helmet", "Crown", "crown", NULL }, { "shield", NULL }, { "boot", "glove", "gauntlet", "shoe", NULL }, { "girdle", NULL }, @@ -26,7 +26,7 @@ { NULL }, { NULL }, { NULL }, -{ "food", "waybread", "roast bird", "water", "booze", "cabbage", "carrot", "chocolate", "clover", "mint sprig", "bread", "cake", "fish", "steak", "apple", "potato", NULL }, +{ "apple", "booze", "bread", "cabbage", "cake", "carrot", "chocolate", "clover", "cup ", "egg", "fish", "food", "mint sprig", "mushroom", "onion", "orange", "potato", "roast bird", "steak", "waybread", "water", NULL }, { NULL }, { NULL }, { NULL }, @@ -36,7 +36,7 @@ { NULL }, { NULL }, { NULL }, -{ "ruby", "diamond", "pearl", "emerald", "sapphire", NULL }, +{ "diamond", "emerald", "gold nugget", "pearl", "ruby", "sapphire", NULL }, { "coin", NULL }, { NULL }, { NULL }, @@ -60,24 +60,24 @@ { "wand", "staff", NULL }, { "horn", NULL }, { "amulet", NULL }, -{ "ring ", "a ring", NULL }, +{ "ring", "Ring ", NULL }, { "scroll", NULL }, -{ "grimore", "treatise", "manual", "tome", "spellbook", NULL }, -{ "lab book", "guidebook", "notebook", "formulary", "tables", "recipe book", "pamphlet", "lab notes", "handbook", "guide ", "cookbook", NULL }, +{ "grimore", "grimoire", "hymnal", "manual", "prayerbook", "sacred text", "spellbook", "testiment", "treatise", "tome", NULL }, +{ "book", "catalog", "codex", "collection", "compendium", "compilation", "divine work", "encyclopedia", "exposition", "file ", "formulary", "guide ", "holy book ", "holy record ", "index", "moral text", "notes", "note", "pamphlet", "record ", "tables", "transcript", "volume", NULL }, { NULL }, -{ "potion", NULL }, +{ "potion", "bottle", NULL }, { NULL }, -{ "balm ", "dust ", NULL }, +{ "balm ", "dust ", "figurine", NULL }, { NULL }, -{ "Improve", "Lower Weapon", "Enchant Weapon", "Prepare Weapon", "Enchant Armor", NULL }, +{ "Improve", "Lower Weapon", "Enchant Weapon", "Prepare Weapon", "Enchant Armour", NULL }, { NULL }, -{ "talisman", "writing pen", "lockpick", NULL }, +{ "holy symbol", "lockpick", "talisman", "writing pen", NULL }, { NULL }, { "key", "Key", NULL }, { NULL }, { NULL }, -{ "pixie dust", "claw", "ectoplasm", "corpse", "wing", "residue", "lich dust", "heart", "liver", "orc chop", "stinger", "beholdereye", "head", "hand", "foot", NULL }, -{ "dirt", NULL }, +{ "arm", "claw", "corpse", "dragon scale", "ectoplasm", "eye", "foot", "hand", "head", "heart", "icor", "leg", "lich dust", "liver", "orc chop", "pixie dust", "residue", "skin", "stinger", "tongue", "tooth", "wing", NULL }, +{ "dirt", "lead", "mandrake root", "pile", "rock", "stone", NULL }, { NULL }, { NULL }, { NULL }, @@ -96,7 +96,7 @@ { NULL }, { NULL }, { NULL }, -{ "icecube", "Glowing Crystal", "library card", NULL }, +{ "clock", "flower", "Gate Pass", "Glowing Crystal", "gravestone", "icecube", "library card", "Port Pass", "rose", NULL }, { NULL }, { NULL }, { NULL }, Index: client/player.c diff -u client/player.c:1.3 client/player.c:1.4 --- client/player.c:1.3 Sun Jun 13 15:19:52 1999 +++ client/player.c Wed Jul 19 23:49:32 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_player_c = - * "$Id: player.c,v 1.3 1999/06/13 22:19:52 cvs Exp $"; + * "$Id: player.c,v 1.4 2000/07/20 06:49:32 cvs Exp $"; */ #include @@ -187,8 +187,10 @@ * the same, drop it */ if (commdiff>cpl.command_window && !must_send && !strcmp(command, last_command)) { +#if 0 /* Obnoxious warning message we don't need */ fprintf(stderr,"Wont send command %s - window oversized %d %d\n", command, csocket.command_sent, csocket.command_received); +#endif } else { SockList sl; From bugs at real-time.com Thu Jul 20 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007200710.e6K7A2m19610@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Fri Jul 21 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007210710.e6L7A2W01318@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Sat Jul 22 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007220710.e6M7A1L09012@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From tanner at real-time.com Sat Jul 22 19:23:44 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] Purify and crossfire? In-Reply-To: <200007180422.VAA14261@tesla.EECS.Berkeley.EDU>; from peterm@tesla.EECS.Berkeley.EDU on Mon, Jul 17, 2000 at 09:22:26PM -0700 References: <200007180422.VAA14261@tesla.EECS.Berkeley.EDU> Message-ID: <20000722192344.B28150@real-time.com> I have purify for solaris. But I don't have the time to go through all of the error messages. I'd be happy to compile/link with purify and post the logs. Would that be acceptable? Quoting Peter Mardahl (peterm@tesla.EECS.Berkeley.EDU): > > Does anyone have access to Purify to run Crossfire under it? > > That might help a lot in finding some of the problems which > (admittedly decreasingly thanks to lots of recent bugfixes) > continue to plague crossfire. > > I had a go at using Electric Fence on crossfire recently, > without much result. > > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From bugs at real-time.com Sun Jul 23 02:10:03 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007230710.e6N7A3i16204@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Mon Jul 24 02:10:03 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:25 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007240710.e6O7A3l23636@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Tue Jul 25 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007250710.e6P7A1s00902@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From mwedel at scruznet.com Wed Jul 26 01:25:58 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] CVS update: crossfire/lib/adm Message-ID: <200007260625.XAA23520@boltzmann.eecs.berkeley.edu> Date: Tuesday July 25, 2000 @ 23:25 Author: cvs Update of /home/cvs/CVS/crossfire/lib/adm In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv23516/lib/adm Modified Files: map_info map_check Log Message: lib/adm/map_info, lib/adm/map_check: Update to use new layout of installed files (share/crossfire), know about random exits (it doesn't do any checking to make sure the values are sane, which it probably should, but at least it won't complain about them), update to use /usr/bin/perl. MSW 7/25/2000 **************************************** Index: crossfire/lib/adm/map_info diff -u crossfire/lib/adm/map_info:1.1 crossfire/lib/adm/map_info:1.2 --- crossfire/lib/adm/map_info:1.1 Fri Apr 2 11:10:08 1999 +++ crossfire/lib/adm/map_info Tue Jul 25 23:25:58 2000 @@ -1,4 +1,4 @@ -#!/usr/local/bin/perl +#!/usr/bin/perl # # This program is meant to use check crossfire (version 0.90.?) maps. # Program wanderers through mapfiles and reports all objects that @@ -13,11 +13,13 @@ # are not connected. This can be annoying at times, since many maps use # these objects for decorations. $CONNECTED = 0; -$LIB = "/home/hugin/a/crossfire/crossfire/lib"; +$LIB = "/home/hugin/a/crossfire/cf-installroot/share/crossfire"; $ARCH = "$LIB/archetypes"; $FACES = "$LIB/faces"; $ANIM = "$LIB/animations"; $MAPS = "$LIB/maps"; +# Set VERBOSE=1 if you want more output +$VERBOSE=0; if (! $ARGV[0]) { print "Usage: wanderer.pl map-directory ... > output.log\n"; @@ -117,19 +119,30 @@ print "Error: file $file isn't mapfile.\n"; return; } - print "Testing $file, "; - print /^name (.+)$/ ? $1 : "No mapname"; - print ", size [", /^x (\d+)$/ ? $1 : 16; - print ",", /^y (\d+)/ ? $1 : 16, "]"; - - if (! /^msg$/) { - print ", No message\n"; - } elsif (/(\w+@\S+)/) { - print ", $1\n"; - } else { - print ", Unknown\n"; + if ($VERBOSE) { + print "Testing $file, "; + print /^name (.+)$/ ? $1 : "No mapname"; + print ", size [", /^x (\d+)$/ ? $1 : 16; + print ",", /^y (\d+)/ ? $1 : 16, "]"; + + if (! /^msg$/) { + print ", No message\n"; + } elsif (/(\w+@\S+)/) { + print ", $1\n"; + } else { + print ", Unknown\n"; + } + $printmap=0; + } + else { + $name= /^name (.+)$/ ? $1 : "No mapname"; + $x= /^x (\d+)$/ ? $1 : 16; + $y= /^y (\d+)/ ? $1 : 16; + $mapname="Map $file, $name, size [$x, $y]\n" ; + $printmap=1; } + while () { if (($m = (@_ = /^arch \S+\s*$/g)) > 1) { $parent = /^arch (\S+)\s*$/; @@ -145,6 +158,7 @@ } elsif (/^end$/) { &check_obj ("$inv$_"); } else { + if ($printmap) { print "$mapname"; $printmap=0;} print " Error: Corrupted map file $file.\nSegment:\n$_\nLine: $.\n"; } } @@ -152,6 +166,7 @@ } elsif (/^More$/ || $m == 1) { &check_obj ($_); } else { + if ($printmap) { print "$mapname"; $printmap=0;} print " Error: Corrupted map file $file.\nSegment:\n$_\nLine: $.\n"; } } @@ -167,12 +182,14 @@ if (! $arches{$1} && $last ne $1) { $last = $1; + if ($printmap) { print "$mapname"; $printmap=0;} print " Error: Object $last is not defined in archetypes file ($x,$y), arch=$arch\n"; $missing{$last}++; } elsif ($ex{$1}) { &examine_exit ($_); } elsif ($tele{$1}) { if (/^food -?\d+$/) { + if ($printmap) { print "$mapname"; $printmap=0;} print " Error: Teleport $1 has food field.\n"; } else { @@ -180,9 +197,13 @@ } } elsif ($conn{$1} && ! /^connected -?\d+$/) { $last = $1; - print " Warning: Object $last has not been connected, $x,$y\n" if ($CONNECTED); + if ($CONNECTED) { + if ($printmap) { print "$mapname"; $printmap=0;} + print " Warning: Object $last has not been connected, $x,$y\n" + } } elsif ($players{$1} && $last ne $1 && ! /^type / ) { $last = $1; + if ($printmap) { print "$mapname"; $printmap=0;} print " Error: Player $last found in the map.\n"; } elsif ($1 eq "scroll" && ! /^msg$/) { $last = $1; @@ -197,13 +218,20 @@ $objects{$1}++; if (/^color_fg (\S+)$/ || /^color_bg (\S+)$/) { $last = $arch; + if ($printmap) { print "$mapname"; $printmap=0;} print " Warning: Object ".$arch." is setting color ($1), $x,$y\n"; } if (/^animation (\S+)$/) { - print "Error: Object $arch is using an unknown animation $1\n" if (! $anim{$1}); + if (! $anim{$1}) { + if ($printmap) { print "$mapname"; $printmap=0;} + print "Error: Object $arch is using an unknown animation $1\n" + } } if (/^face (\S+)$/) { - print "Error: Object $arch is using an unknown face $1\n" if (! $faces{$1}); + if (! $faces{$1}) { + if ($printmap) { print "$mapname"; $printmap=0;} + print "Error: Object $arch is using an unknown face $1\n" + } } } @@ -233,18 +261,21 @@ if (/^food (-?\d+)$/) { # old style exits, doesn't work with crossfire 0.90-1 + if ($printmap) { print "$mapname"; $printmap=0;} print " Error: ", &obj_name($_), " ($x1,$y1) -> ", "Old style level [$1] ($x,$y)\n"; } elsif (! defined ($to)) { # print " Closed: ", &obj_name($_), " ($x1,$y1)\n"; } else { # These are currently used be crossfire + return if ($to eq "/!"); if ($to =~ m!^/!) { $cdir = "$MAPS"; } else { ($cdir) = $file =~ m!(.*/)!; } if (! -f "$cdir$to") { + if ($printmap) { print "$mapname"; $printmap=0;} print " Missing: ", &obj_name($_), " ($x1,$y1) -> $to ($x,$y)\n"; } else { # print " OK: ", &obj_name($_), " ($x1,$y1) -> $to ($x,$y)\n"; @@ -258,7 +289,7 @@ opendir (DIR , $dir) || die "Can't open directory : $dir\n"; while ($file = readdir (DIR)) { - next if ($file eq "." || $file eq ".."); + next if ($file eq "." || $file eq ".." || $file eq "CVS"); $file = "$dir/$file"; push (@dirs, $file) if (-d $file); push (@maps, $file) if (-f $file); Index: crossfire/lib/adm/map_check diff -u crossfire/lib/adm/map_check:1.1 crossfire/lib/adm/map_check:1.2 --- crossfire/lib/adm/map_check:1.1 Fri Apr 2 11:10:08 1999 +++ crossfire/lib/adm/map_check Tue Jul 25 23:25:58 2000 @@ -1,4 +1,4 @@ -#!/usr/local/bin/perl +#!/usr/bin/perl # # (C) Copyright Markus Weber, 1994. All rights reserved. # Permission is granted to use, copy, and modify for non-commercial use. @@ -9,11 +9,11 @@ # archdb=pathname-of-archetype-database *** not used *** # default ./ARCHDB .{dir,pag} # archetypes=pathname-of-archetypes-file -# default $cfdir/lib/archetypes +# default $cfdir/share/crossfire/archetypes # cfdir=pathname-to-crossfire-installation # default /opt/cf0901 (hardcoded) # mapdir=pathname-of-map-directory -# default $cfdir/lib/maps +# default $cfdir/share/crossfire/maps # start-map=map-path-of-starting map # default (init in archetypes) @@ -24,7 +24,7 @@ # ARGUMENT PROCESSING # # preset options -$cfdir = "/home/hugin/a/crossfire/cftest"; +$cfdir = "/home/hugin/a/crossfire/cf-installroot"; # loop thru arg vector while (@ARGV) { @@ -56,8 +56,8 @@ } # post-process -$mapdir = "$cfdir/lib/maps" unless defined($mapdir); -$archetypes = "$cfdir/lib/archetypes" unless defined($archetypes); +$mapdir = "$cfdir/share/crossfire/maps" unless defined($mapdir); +$archetypes = "$cfdir/share/crossfire/archetypes" unless defined($archetypes); print STDERR "DBG: archetypes=$archetypes\n" if $debug > 5; print STDERR "DBG: archdb=$archdb\n" if $debug > 5; print STDERR "DBG: mapdir=$mapdir\n" if $debug > 5; @@ -335,7 +335,7 @@ # this is check 4, finally. # if exit map can't be opened, complain and continue # - if ( ! (-r "$mapdir$exit") ) { + if ( (! -r "$mapdir$exit") && ( $exit ne "/!") ) { #print STDERR "ERROR: map $map, arch $arch, line $lines, no such exit $exit\n"; print "ERROR: map $map, arch $arch, line $lines, no such exit $exit ($rx, $ry, to $x, $y)\n"; next; From mwedel at scruznet.com Wed Jul 26 01:25:59 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] CVS update: crossfire Message-ID: <200007260625.XAA23526@boltzmann.eecs.berkeley.edu> Date: Tuesday July 25, 2000 @ 23:25 Author: cvs Update of /home/cvs/CVS/crossfire In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv23516 Modified Files: CHANGES Log Message: lib/adm/map_info, lib/adm/map_check: Update to use new layout of installed files (share/crossfire), know about random exits (it doesn't do any checking to make sure the values are sane, which it probably should, but at least it won't complain about them), update to use /usr/bin/perl. MSW 7/25/2000 **************************************** Index: crossfire/CHANGES diff -u crossfire/CHANGES:1.113 crossfire/CHANGES:1.114 --- crossfire/CHANGES:1.113 Wed Jul 19 23:45:48 2000 +++ crossfire/CHANGES Tue Jul 25 23:25:59 2000 @@ -16,6 +16,12 @@ small - this just lets others know that the file has changed if nothing else. With this, include the file(s) that you changed. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +lib/adm/map_info, lib/adm/map_check: Update to use new layout of installed +files (share/crossfire), know about random exits (it doesn't do any checking +to make sure the values are sane, which it probably should, but at least it +won't complain about them), update to use /usr/bin/perl. MSW 7/25/2000 + server/resurrection.c include/spellist.h: PeterM: fixed a few unintended things about resurrection: experience removal was wrong, spellpoints/levels From bugs at real-time.com Wed Jul 26 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007260710.e6Q7A1010560@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From mwedel at scruznet.com Wed Jul 26 13:24:39 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] CVS update: crossfire/random_maps Message-ID: <200007261824.LAA27392@boltzmann.eecs.berkeley.edu> Date: Wednesday July 26, 2000 @ 11:24 Author: peterm Update of /home/cvs/CVS/crossfire/random_maps In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv27384 Modified Files: treasure.c Log Message: Crashing bug fixed. This crash should actually not have come up; it was a result of an illegal wall style. Long ago I had fixed the archetypes to prevent this problem, but it got, uh, "unfixed." --PeterM **************************************** Index: crossfire/random_maps/treasure.c diff -u crossfire/random_maps/treasure.c:1.6 crossfire/random_maps/treasure.c:1.7 --- crossfire/random_maps/treasure.c:1.6 Tue Jun 20 21:54:57 2000 +++ crossfire/random_maps/treasure.c Wed Jul 26 11:24:38 2000 @@ -1,6 +1,6 @@ /* * static char *rcsid_treasure_c = - * "$Id: treasure.c,v 1.6 2000/06/21 04:54:57 peterm Exp $"; + * "$Id: treasure.c,v 1.7 2000/07/26 18:24:38 peterm Exp $"; */ /* @@ -678,13 +678,15 @@ object *wallface; door=doorlist[i]; wallface=retrofit_joined_wall(map,door->x,door->y,1); - retrofit_joined_wall(map,door->x-1,door->y,0); - retrofit_joined_wall(map,door->x+1,door->y,0); - retrofit_joined_wall(map,door->x,door->y-1,0); - retrofit_joined_wall(map,door->x,door->y+1,0); - door->face = wallface->face; - if(!QUERY_FLAG(wallface,FLAG_REMOVED)) remove_ob(wallface); - free_object(wallface); + if(wallface!=NULL) { + retrofit_joined_wall(map,door->x-1,door->y,0); + retrofit_joined_wall(map,door->x+1,door->y,0); + retrofit_joined_wall(map,door->x,door->y-1,0); + retrofit_joined_wall(map,door->x,door->y+1,0); + door->face = wallface->face; + if(!QUERY_FLAG(wallface,FLAG_REMOVED)) remove_ob(wallface); + free_object(wallface); + } } } } From mwedel at scruznet.com Wed Jul 26 13:27:10 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] CVS update: crossfire Message-ID: <200007261827.LAA27423@boltzmann.eecs.berkeley.edu> Date: Wednesday July 26, 2000 @ 11:27 Author: peterm Update of /home/cvs/CVS/crossfire In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv27415 Modified Files: CHANGES Log Message: Crashing bug fixed. This crash should actually not have come up; it was a result of an illegal wall style. Long ago I had fixed the archetypes to prevent this problem, but it got, uh, "unfixed." --PeterM **************************************** Index: crossfire/CHANGES diff -u crossfire/CHANGES:1.114 crossfire/CHANGES:1.115 --- crossfire/CHANGES:1.114 Tue Jul 25 23:25:59 2000 +++ crossfire/CHANGES Wed Jul 26 11:27:09 2000 @@ -17,6 +17,10 @@ else. With this, include the file(s) that you changed. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +random_maps/treasure.c: potential crash bug fixed. Only applied +when a bad archetype was given as a wallstyle. I will also put +in a redundant archetypes fix. --PeterM 7/26/00 + lib/adm/map_info, lib/adm/map_check: Update to use new layout of installed files (share/crossfire), know about random exits (it doesn't do any checking to make sure the values are sane, which it probably should, but at least it From mwedel at scruznet.com Wed Jul 26 13:29:09 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] CVS update: maps/styles/wallstyles Message-ID: <200007261829.LAA27450@boltzmann.eecs.berkeley.edu> Date: Wednesday July 26, 2000 @ 11:29 Author: peterm Update of /home/cvs/CVS/maps/styles/wallstyles In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv27447 Modified Files: cave2 Log Message: Fixed illegal wallstyle cave2 so that it shall work properly. **************************************** Index: maps/styles/wallstyles/cave2 diff -u maps/styles/wallstyles/cave2:1.1 maps/styles/wallstyles/cave2:1.2 --- maps/styles/wallstyles/cave2:1.1 Thu Jun 8 22:38:25 2000 +++ maps/styles/wallstyles/cave2 Wed Jul 26 11:29:09 2000 @@ -8,5 +8,5 @@ x 6 y 6 end -arch rough_wall_0 +arch roughwall_0 end From peterm at tesla.EECS.Berkeley.EDU Wed Jul 26 13:41:22 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] Re: [CF List] Server crashes during Dragon Quest (CVS 07/21) In-Reply-To: Your message of "Tue, 25 Jul 2000 23:25:57 PDT." <397E8475.DC6A3C7A@scruznet.com> Message-ID: <200007261841.LAA20262@tesla.EECS.Berkeley.EDU> Hello, This was fundamentally a problem with the style map styles/wallstyles/cave2. I realized my wall code couldn't handle something named rough_wall but could handle something called roughwall, so I made duplicate arches of rough_wall named roughwall. This provided backward compatibility with existing maps without requiring a change, and allowed my random map code to work properly. To fix it, I fixed styles/wallstyles/cave2 to use "roughwall" instead of "rough_wall". I also patched "treasure.c" so that it won't crash even if the wallstyle is improper. I do not believe that the failure to find "rough_2_1_1" caused the crashing for Mr. McKenney, because that code was written to gracefully fail: indeed, in the map, it always uses the "+" style of wall (which looks ugly, but still blocks movement) instead of failing on not finding "rough_2_1_1". Anyway, the QUICK fix to this is to simply change the name of the archetype in maps/styles/wallstyles/cave2 from rough_wall to roughwall I could not repeat Mr. McKenney's crash during my own testing: instead I found a different crash, which I fixed. I will continue trying to repeat Mr. McKenney's crash. PeterM > Frank McKenney wrote: > > Failure #1 > > ---------- > > --snip-- > > Couldn't find archetype rough_2_1_1 > > Couldn't find archetype rough_2_1_1 > > Couldn't find archetype rough_2_1_1 > > That object does not appear to exist. I think it should in fact be a > rough_wall_2_1_1 - I don't see rough_2_1_1 being used in any of the map files > (include the styles), so my initial guess would be that the random_map code i >s > improperly truncating the name. > > Since I see the SIGSEGV right after that, my guess is that the removing a > removed object is just an after effect. > > Looking at random_map/wall.c (around line 170), it does appear that the code > there does not deal with wall codes that may have an underscore in the name. > > I'm not familiar specifically what that function does. I do note that all t >he > styles/wall files are a format of ..._0 (ie, rough_wall_0, gwall_0, etc), so >it > would seem possible that maybe that fact could be used in truncating the wall > name. > > The other possibilities I could think of in that function is to check the ne >xt > character - if a number, presume that is the underscore we want to stop at, i >f > another letter, presume it is part of the arch basename. > > Peter - you probably know more about that section of code than I do. > > I don't know if the editor or any other functions may have similar assumptio >ns > about the autojoining walls or not. If so, either those need to be fixed or > perhaps we should rename rough_wall to be roughwall instead (I don't know how > many maps may be using the first form that would require updating) > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From bugs at real-time.com Thu Jul 27 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007270710.e6R7A2A20370@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=28 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Fri Jul 28 02:03:58 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] [Bug 28] Changed - Torches dim and go out, but icon does not change Message-ID: <200007280703.e6S73wO29329@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=28 *** shadow/28 Mon Jul 24 14:39:16 2000 --- shadow/28.tmp.29326 Fri Jul 28 02:03:58 2000 *************** *** 3,10 **** Version: 0.95.6 Platform: Other OS/Version: Linux ! Status: NEW ! Resolution: Severity: minor Priority: P4 Component: server --- 3,10 ---- Version: 0.95.6 Platform: Other OS/Version: Linux ! Status: RESOLVED ! Resolution: FIXED Severity: minor Priority: P4 Component: server *************** *** 25,27 **** --- 25,38 ---- in the Inventory until the character is logged out and later returns. Visually annoying, but as far as I can tell, harmless otherwise. + + ------- Additional Comments From mwedel@scruz.net 2000-07-28 02:03 ------- + From CHANGES file: + server/time.c: Update the change_object function such that if the object + is in a players inventory, send a delete & send_item for the object that + has changed (the delete + send_item is necessary due to the ways objects + change, so we just can't sent a update_item). This fixes the 'torches + go dim & then out but client inventory not updated' bug, and likely fixes + some other problems - I am not sure how many other objects out there + change. MSW 7/28/2000 + From bugs at real-time.com Fri Jul 28 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007280710.e6S7A2229390@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From mwedel at scruznet.com Fri Jul 28 02:10:21 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] CVS update: crossfire/server Message-ID: <200007280710.AAA24271@boltzmann.eecs.berkeley.edu> Date: Friday July 28, 2000 @ 0:10 Author: cvs Update of /home/cvs/CVS/crossfire/server In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv24266/server Modified Files: time.c Log Message: server/time.c: Update the change_object function such that if the object is in a players inventory, send a delete & send_item for the object that has changed (the delete + send_item is necessary due to the ways objects change, so we just can't sent a update_item). This fixes the 'torches go dim & then out but client inventory not updated' bug, and likely fixes some other problems - I am not sure how many other objects out there change. MSW 7/28/2000 **************************************** Index: crossfire/server/time.c diff -u crossfire/server/time.c:1.9 crossfire/server/time.c:1.10 --- crossfire/server/time.c:1.9 Tue Jun 13 09:58:41 2000 +++ crossfire/server/time.c Fri Jul 28 00:10:21 2000 @@ -1,12 +1,12 @@ /* * static char *rcsid_time_c = - * "$Id: time.c,v 1.9 2000/06/13 16:58:41 jec Exp $"; + * "$Id: time.c,v 1.10 2000/07/28 07:10:21 cvs Exp $"; */ /* CrossFire, A Multiplayer game for X-windows - Copyright (C) 1994 Mark Wedel + Copyright (C) 2000 Mark Wedel Copyright (C) 1992 Frank Tore Johansen This program is free software; you can redistribute it and/or modify @@ -23,7 +23,7 @@ along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - The author can be reached via e-mail to master@rahul.net + The author can be reached via e-mail to mwedel@scruz.net */ /* @@ -626,7 +626,7 @@ * Modified this routine to allow held objects. b.t. */ void change_object(object *op) { /* Doesn`t handle linked objs yet */ - object *tmp,*env; + object *tmp,*env,*pl; int i,j; if(op->other_arch==NULL) { @@ -646,7 +646,15 @@ tmp->stats.hp=op->stats.hp; /* The only variable it keeps. */ if(env) { tmp->x=env->x,tmp->y=env->y; - insert_ob_in_ob(tmp,env); + tmp=insert_ob_in_ob(tmp,env); + /* If this object is the players inventory, we need to tell the + * client of the change. Insert_ob_in_map takes care of the + * updating the client, so we don't need to do that below. + */ + if ((pl=is_player_inv(env))!=NULL) { + esrv_del_item(pl->contr, op->count); + esrv_send_item(pl, tmp); + } } else { j=find_first_free_spot(tmp->arch,op->map,op->x,op->y); if (j==-1) /* No free spot */ From mwedel at scruznet.com Fri Jul 28 02:10:22 2000 From: mwedel at scruznet.com (Crossfire CVS devel) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] CVS update: crossfire Message-ID: <200007280710.AAA24277@boltzmann.eecs.berkeley.edu> Date: Friday July 28, 2000 @ 0:10 Author: cvs Update of /home/cvs/CVS/crossfire In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv24266 Modified Files: CHANGES Log Message: server/time.c: Update the change_object function such that if the object is in a players inventory, send a delete & send_item for the object that has changed (the delete + send_item is necessary due to the ways objects change, so we just can't sent a update_item). This fixes the 'torches go dim & then out but client inventory not updated' bug, and likely fixes some other problems - I am not sure how many other objects out there change. MSW 7/28/2000 **************************************** Index: crossfire/CHANGES diff -u crossfire/CHANGES:1.115 crossfire/CHANGES:1.116 --- crossfire/CHANGES:1.115 Wed Jul 26 11:27:09 2000 +++ crossfire/CHANGES Fri Jul 28 00:10:21 2000 @@ -17,6 +17,14 @@ else. With this, include the file(s) that you changed. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +server/time.c: Update the change_object function such that if the object +is in a players inventory, send a delete & send_item for the object that +has changed (the delete + send_item is necessary due to the ways objects +change, so we just can't sent a update_item). This fixes the 'torches +go dim & then out but client inventory not updated' bug, and likely fixes +some other problems - I am not sure how many other objects out there +change. MSW 7/28/2000 + random_maps/treasure.c: potential crash bug fixed. Only applied when a bad archetype was given as a wallstyle. I will also put in a redundant archetypes fix. --PeterM 7/26/00 From bugs at real-time.com Sat Jul 29 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007290710.e6T7A1e05148@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Sun Jul 30 02:10:02 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007300710.e6U7A2e12757@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From bugs at real-time.com Mon Jul 31 02:10:01 2000 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 17:57:26 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200007310710.e6V7A1t29766@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=18 http://bugzilla.real-time.com/show_bug.cgi?id=27 http://bugzilla.real-time.com/show_bug.cgi?id=33 http://bugzilla.real-time.com/show_bug.cgi?id=34 From taporg at yahoo.com Sat Jul 1 01:43:43 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] png images Message-ID: <20000701064343.20898.qmail@web218.mail.yahoo.com> Hello, all, I'm guessing that by adding PNG support, we've implicitly removed any color palette restrictions for created images? While I can see the argument that some people may still run bitmap versions, I'd have more difficulty believing that people running CF in color would be restriced to 256 colors. The reason the color is significant is that the new 32x32 image size combined with unlimited color use would make creating images orders of magnitude easier for artists (like me :). That said, I've just uploaded several new png images to the incoming directory at ftp.ifi.uio.no. Hopefully, they will be useful, as I did ignore any existing palettes while creating them. After having gone looked over the converted archs, I also composed the list png_todo.txt of png files which are as of yet in the ugly scaled up form. In cases where I wasn't sure, I left the image name on the list. I agree with another poster that a number of the images would look good if simply taken from their original xpm form, and converted to png without scaling. *whew* Having done all of that, I figured it would only be right to bring up all of the comments and nitpicks I have. Anyways... ... The image for a non-destructable earthwall has somehow changed to a pillar, making it trivial to tell apart from the destructable ones. ... With the isometric scheme that the newly drawn tiles are using, it would make sense for a two-space creature (for instance, a unicorn), to change shape if it changes direction and starts walking downward. Just wondering whether the server code would know how to handle such events gracefully. :) ... Also regarding the isometric perspective - when an isometrically drawn monster shown facing south starts walking sideways, it looks slightly more awkward that if a flat iconic version of the monster starts walking sideways. I think it's something to consider ... redrawing monsters isometrically may imply needing to draw the monster facing in other directions as well. ... Please please please be sure to save the original xpms somewhere, even with better pngs available, and even if all of the xpms end up removed from the arch directories. There are a number of nice icons in that image set, and drawing well at 24x24 isn't easy. ... Has anyone tried going into a room full of kobolds, orcs, gnolls, ogres, madmen, and maybe zombies as well under the png image set? I haven't, myself, but I bring it up because I wonder how easily distinguishable the different monsters are. Individually, they're well drawn, although their color schemes are all so similar, that I think it's worth checking to make sure that they do indeed succeed in looking different. And that's about it for now. -j __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From mailman-owner at lists.real-time.com Sat Jul 1 05:03:56 2000 From: mailman-owner at lists.real-time.com (mailman-owner@lists.real-time.com) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] lists.real-time.com mailing list memberships reminder Message-ID: <200007011003.e61A3un18973@sprite.real-time.com> This is a reminder, sent out once a month, about your lists.real-time.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, crossfire-announce-request@lists.real-time.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.real-time.com. Thanks! Passwords for crossfire-list@lists.real-time.com: List Password // URL ---- -------- crossfire-announce@lists.real-time.com YcVE https://mailman.real-time.com/mailman/options/crossfire-announce/crossfire-list@lists.real-time.com From mwedel at scruznet.com Sat Jul 1 13:50:40 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] png images References: <20000701064343.20898.qmail@web218.mail.yahoo.com> Message-ID: <395E3D80.77ECD7EB@scruznet.com> Jonathan Taporg wrote: > > Hello, all, > > I'm guessing that by adding PNG support, we've > implicitly removed any color palette restrictions > for created images? While I can see the argument > that some people may still run bitmap versions, I'd > have more difficulty believing that people running > CF in color would be restriced to 256 colors. The > reason the color is significant is that the new > 32x32 image size combined with unlimited color use > would make creating images orders of magnitude easier > for artists (like me :). There is still some color restrictions. Anyone with an 8 bit display is restricted to 256 colors, and 8 bit displays are still somehwat common. Unfortunately, I don't seem to have a list anyplace of what colors he chose were. I guess it would not be too hard to write a simple script to extract the color information from the png images. > After having gone looked over the converted archs, > I also composed the list png_todo.txt of png files > which are as of yet in the ugly scaled up form. In > cases where I wasn't sure, I left the image name > on the list. I agree with another poster that > a number of the images would look good if simply > taken from their original xpm form, and converted > to png without scaling. And for some objects, that probably does not create any harm, as just in terms of scaling, some could easily be smaller than others. > > *whew* Having done all of that, I figured it would > only be right to bring up all of the comments and > nitpicks I have. Anyways... > > ... The image for a non-destructable earthwall has > somehow changed to a pillar, making it trivial to > tell apart from the destructable ones. I notice that the entire look of the wall/bwall has changed. The normally walls are a grey and not the yellow like the old ones, so thingsl like the stoneblock and earthwall really stand out. > > ... With the isometric scheme that the newly drawn > tiles are using, it would make sense for a two-space > creature (for instance, a unicorn), to change shape > if it changes direction and starts walking downward. > Just wondering whether the server code would know > how to handle such events gracefully. :) Nope - the dimension/x,y of multipart objects are not mean to be dynamic. I suppose that support could be added. > > ... Also regarding the isometric perspective - when > an isometrically drawn monster shown facing south > starts walking sideways, it looks slightly more > awkward that if a flat iconic version of the monster > starts walking sideways. I think it's something to > consider ... redrawing monsters isometrically may > imply needing to draw the monster facing in other > directions as well. This is supported by the server - any creature can have up to about 8 facings - presently, pretty much only players actually have 8 facings, with most other monters have 1, 2, or 4. > > ... Please please please be sure to save the original > xpms somewhere, even with better pngs available, and > even if all of the xpms end up removed from the arch > directories. There are a number of nice icons in > that image set, and drawing well at 24x24 isn't easy. They will off course still be all those images in all the prior releases out on the ftp servers. > > ... Has anyone tried going into a room full of > kobolds, orcs, gnolls, ogres, madmen, and maybe > zombies as well under the png image set? I haven't, > myself, but I bring it up because I wonder how easily > distinguishable the different monsters are. > Individually, they're well drawn, although their > color schemes are all so similar, that I think it's > worth checking to make sure that they do indeed > succeed in looking different. Hopefully, there are not any maps that mix the different monster types so badly. From frank_mckenney at mindspring.com Sun Jul 2 16:53:28 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] Spell-casting occasionally "stutters" in 0.95.6 Message-ID: <200007022053.QAA10991@maynard.mail.mindspring.net> Occasionally when I invoke (fire) a spell Crossfire apparently decides to re-invoke it on its own. For example, in the Hall of Bones (Ruins of Euthville), I will hold down the Left-Shift key and press "northeast" (keypad 9) once briefly to fire one Holy Orb. For the most part this works as expected, but every so often I'll notice that my Grace drops as if I had issued two or three of these. I have noticed this most frequently in areas of heavy animation (e.g the Hall of Bones), and my first assumption was that somehow I was triggering a key autorepeat or something similar. The trouble with this assumption is that _only_ spells get "stuttered". Movement and other keystrokes do not appear to suffer the same problem. Has anyone else noticed this effect? Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From taporg at yahoo.com Sun Jul 2 19:46:15 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] png images Message-ID: <20000703004615.21874.qmail@web215.mail.yahoo.com> Mark Wedel wrote: > There is still some color restrictions. Anyone with > an 8 bit display is restricted to 256 colors, and 8 > bit displays are still somehwat common. Hmm... perhaps you know better than me, although this statement somewhat surprises me, because I think it's fair to say that highcolor cards were available for mid-level pcs back around 1995. Also, so long as crossfire supports the bitmap images, I don't see why it would be necessary for both of the supported image sets to be limited in color. Clearly, I'm biased on the subject, because I prefer to draw without color restrictions. And while it may take more skill to do a good job on low-color image, I believe that well-done high color images can look noticably better than ones with the existing colorset. > > ... Has anyone tried going into a room full of > > kobolds, orcs, gnolls, ogres, madmen, and maybe > > zombies as well under the png image set? [...] > > Hopefully, there are not any maps that mix the > different monster types so badly. Since asking the question, I made a point of checking on my own... There's actually no problem in distinguishing the monsters at all. It isn't uncommon to find kobolds, orcs, gnolls, and ogres mixed together, which makes sense since they are all goblin races. The only possible source of confusion would be between orcs and kobolds, since the kobold is basically drawn as a miniaturized version of the orc. -j __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From crossfire-announce-request at lists.real-time.com Mon Jul 3 12:11:17 2000 From: crossfire-announce-request at lists.real-time.com (crossfire-announce-request@lists.real-time.com) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] crossfire-announce@lists.real-time.com mailing list reminder Message-ID: <200007031711.e63HBHn02767@sprite.real-time.com> This is a reminder of how to unsubscribe or change your configuration for the address "crossfire-list@lists.real-time.com" on the mailing list crossfire-announce. You need to have your password for these things. YOUR crossfire-announce PASSWORD IS: YcVE To make changes to your subscription, use the password on your options World Wide Web page: https://mailman.real-time.com/mailman/options/crossfire-announce/crossfire-list@lists.real-time.com You can also make such changes via email - send a message to: crossfire-announce-request@lists.real-time.com with the text "help" in the subject or body, and you will be emailed instructions. Questions or comments? Please send them to crossfire-announce-admin@lists.real-time.com. From mwedel at scruznet.com Tue Jul 4 02:21:02 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] png images References: <20000703004615.21874.qmail@web215.mail.yahoo.com> Message-ID: <3961905E.446FB09F@scruznet.com> Jonathan Taporg wrote: > Hmm... perhaps you know better than me, although > this statement somewhat surprises me, because > I think it's fair to say that highcolor cards were > available for mid-level pcs back around 1995. > Also, so long as crossfire supports the bitmap images, > I don't see why it would be necessary for both of > the supported image sets to be limited in color. Many workstations (and x-terminals) only had 8 bit display even fairly recently. While the bitmaps do fine for black & white systems, bitmaps are far inferior to even the xpm images for color systems. And at some point, I would like to get rid of the xpm (reduce distribution size as well as stuff that needs to be supported). > > Clearly, I'm biased on the subject, because I prefer > to draw without color restrictions. And while it may > take more skill to do a good job on low-color image, > I believe that well-done high color images can look > noticably better than ones with the existing colorset. Certainly it is easier to do anything if there is no restrictions. But my own feeling is that why break something that doesn't need to be broken. Someone actually mentioned that he thought it worked better for the images to be a little more iconic than photo realistic. And I think most people will agree that even with the limited color set used for the png's, they still look very nice. i extracted the color list/rgb values from the current png files. As cursory glance, there are some things that can be cleaned up (for example, the second and third entries could almost certainly be moved into one, because no one is likely able to distinguish the difference between that 1 rgb difference). I don't know if these minor differences were caused by the conversion program or in the original files David checked in. #000000 #00007F #000080 #0000BC #0000FF #003100 #003200 #004500 #004F00 #005E5E #006300 #006400 #007300 #007A00 #007F00 #008A00 #008A8A #008B8B #008C00 #009700 #009C00 #00A100 #00A500 #00AA00 #00B000 #00BCBC #00C900 #00CC00 #00CD00 #00EDED #00EEEE #00FF00 #00FFFF #02060A #040B13 #040C13 #06111D #081726 #0A1D30 #0C2339 #0E2843 #0E2943 #102E4C #123456 #1868E0 #1C1C1C #1E90FF #212121 #243442 #2D8A56 #2E8B57 #393939 #3C444C #3D444C #404040 #472415 #555555 #570000 #602D91 #616161 #63321D #634412 #64331E #644513 #717171 #73777B #74777B #7F7F7F #820000 #824227 #892AD6 #8E8E8E #922820 #9D8B5F #9F512C #A0522D #A1A1A1 #A332FF #A9A9A9 #AAAAAA #AF2F5F #B03060 #B12121 #B22222 #BB983F #BE7439 #BFBFBF #C17138 #CD853F #D2691E #D9A41F #DAA520 #E0E0E0 #ED7500 #EE7600 #EFA75F #EFE58B #F0E68C #F97F71 #FA8072 #FEA400 #FEBFCA #FED600 #FF0000 #FF00FF #FF5757 #FFA500 #FFC0CB #FFD700 #FFF #FFFF00 #FFFFFF From crossfire-announce-request at lists.real-time.com Tue Jul 4 02:35:59 2000 From: crossfire-announce-request at lists.real-time.com (crossfire-announce-request@lists.real-time.com) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] crossfire-announce@lists.real-time.com mailing list reminder Message-ID: <200007040735.e647Zxn07335@sprite.real-time.com> This is a reminder of how to unsubscribe or change your configuration for the address "crossfire-list@lists.real-time.com" on the mailing list crossfire-announce. You need to have your password for these things. YOUR crossfire-announce PASSWORD IS: wicky2woo To make changes to your subscription, use the password on your options World Wide Web page: https://mailman.real-time.com/mailman/options/crossfire-announce/crossfire-list@lists.real-time.com You can also make such changes via email - send a message to: crossfire-announce-request@lists.real-time.com with the text "help" in the subject or body, and you will be emailed instructions. Questions or comments? Please send them to crossfire-announce-admin@lists.real-time.com. From norbert.irmer at heim9.tu-clausthal.de Tue Jul 4 02:47:35 2000 From: norbert.irmer at heim9.tu-clausthal.de (Norbert Irmer) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] png images References: <20000703004615.21874.qmail@web215.mail.yahoo.com> <3961905E.446FB09F@scruznet.com> Message-ID: <39619697.B3AF8FC6@heim9.tu-clausthal.de> Mark Wedel wrote: > > > > Clearly, I'm biased on the subject, because I prefer > > to draw without color restrictions. And while it may > > take more skill to do a good job on low-color image, > > I believe that well-done high color images can look > > noticably better than ones with the existing colorset. > > Certainly it is easier to do anything if there is no restrictions. But my own > feeling is that why break something that doesn't need to be broken. Someone > actually mentioned that he thought it worked better for the images to be a > little more iconic than photo realistic. And I think most people will agree > that even with the limited color set used for the png's, they still look very > nice. > I think it would do no harm to allow the number of colors to be unlimited, Since you can setup a true color palette even on a 8 bit display, for example by using 3 bits for red, 3 bits for green, and 2 bits for blue. (I did this a few years ago when using a self written opengl renderer on an old sun workstation with 8 bit display, and the results were quite acceptable) Then the game would still still be playable on old 8 bit displays, and the artists have any freedom they want. From mwedel at scruznet.com Tue Jul 4 22:14:23 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] png images References: <20000703004615.21874.qmail@web215.mail.yahoo.com> <3961905E.446FB09F@scruznet.com> <39619697.B3AF8FC6@heim9.tu-clausthal.de> Message-ID: <3962A80F.CAB51E28@scruznet.com> Norbert Irmer wrote: > > I think it would do no harm to allow the number of colors to be unlimited, > > Since you can setup a true color palette even on a 8 bit display, for example > by using 3 bits for red, 3 bits for green, and 2 bits for blue. > > (I did this a few years ago when using a self written opengl renderer on an old > sun workstation with 8 bit display, and the results were quite acceptable) > > Then the game would still still be playable on old 8 bit displays, and the > artists have any freedom they want. I think there is a difference of philosphy here. While there may be some workarounds/changes that can be done for the client, as I've stated in the past, I see no reason to go that route unless it is really needed. Having it be 'more convenient' to have unlimited colors for png does not qualify in there really needed category. It strikes me as the easy way out (which in terms of crossfire, I generally despise, as these easy ways out then tend to get fixed up by someone else later). Given that, most likely only images which follow the color scheme set forth are ever likely to make it into the official distribution. If someone says 'well, there is no color close to what I really need so I want to add another one', I don't have a problem with that. If instead, the image doesn't use any of the colors and the reason is 'I just didn't want to look at the approved color list', that image is unlikely to get into the official tree. This is fairly harsh standards. OTOH, the current images with the limited color set look very good, and to me, that sort of says that even with limited color sets, very good artwork can be done, so ability to use every color is not needed. Note that if you really want the freedom to develope in any color you want, feel free. It probably would not be hard at all to write a simple script the uses the netpbm utilities to convert whatever images to the 'approved' colors. From scott at campy.tymnet.com Wed Jul 5 01:05:46 2000 From: scott at campy.tymnet.com (scott) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] png images Message-ID: <200007050605.AAA04367@moots.tymnet.com> The only reason to go to unlimited colors from 256 would be if there was a significant feature improvement. To go to unlimited colors only because it allows artists to use unlimited colors is not a sufficient reason. Images of items can clearly be done with a limited number of colors. There needs to be something tangible to justify go to unlimited colors. For instance, if there was an artist interested in greatly expanding the number of fireball images to create a far more visually exciting effect then going to unlimited colors might be justified. Such a situation would probably also suggest solutions on how to go to unlimited colors and still support 256 bit color displays. I think Norbert Irmer's suggestion on how to set up a true color palette on an 8 bit display undercuts the need for supporting unlimited colors. If one can get a true color palette on an 8 bit display then what need is there for supporting unlimited colors? If there were useful colors not included in the 256 supported colors then there would be a greater need for supported unlimited colors. But if one can get "quite acceptable" results within a 256 bit color map then it should be quite acceptable for CF to support only 256 colors. CF is not a 3D imersion game where limited colors interfer with the desired realism. It is an overhead map with objects on squares. Rings are almost as large as players and so on. The goal is not realism, but recognition. The question is whether the player can easily see and identify the item. It has not been demonstrated that more colors make objects easier to recognize. If someone wants to show some unlimited color images as compared to the current 256 color image then that would be an important part of justifying going to unlimited colors. >Date: Tue, 04 Jul 2000 20:14:23 -0700 >From: Mark Wedel >X-Accept-Language: en >Mime-Version: 1.0 >To: crossfire-list@lists.real-time.com >Subject: Re: [CF List] png images >Content-Transfer-Encoding: 7bit >X-Beenthere: crossfire-list@lists.real-time.com >X-Mailman-Version: 2.0beta2 >List-Id: Crossfire Discussion Mailing List > >Norbert Irmer wrote: >> > >> I think it would do no harm to allow the number of colors to be unlimited, >> >> Since you can setup a true color palette even on a 8 bit display, for example >> by using 3 bits for red, 3 bits for green, and 2 bits for blue. >> >> (I did this a few years ago when using a self written opengl renderer on an old >> sun workstation with 8 bit display, and the results were quite acceptable) >> >> Then the game would still still be playable on old 8 bit displays, and the >> artists have any freedom they want. > > I think there is a difference of philosphy here. > > While there may be some workarounds/changes that can be done for the client, as >I've stated in the past, I see no reason to go that route unless it is really >needed. > > Having it be 'more convenient' to have unlimited colors for png does not >qualify in there really needed category. It strikes me as the easy way out >(which in terms of crossfire, I generally despise, as these easy ways out then >tend to get fixed up by someone else later). > > Given that, most likely only images which follow the color scheme set forth are >ever likely to make it into the official distribution. If someone says 'well, >there is no color close to what I really need so I want to add another one', I >don't have a problem with that. If instead, the image doesn't use any of the >colors and the reason is 'I just didn't want to look at the approved color >list', that image is unlikely to get into the official tree. > > This is fairly harsh standards. OTOH, the current images with the limited >color set look very good, and to me, that sort of says that even with limited >color sets, very good artwork can be done, so ability to use every color is not >needed. > > Note that if you really want the freedom to develope in any color you want, >feel free. It probably would not be hard at all to write a simple script the >uses the netpbm utilities to convert whatever images to the 'approved' colors. >_______________________________________________ >crossfire-list mailing list >crossfire-list@lists.real-time.com >https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-announce-request at lists.real-time.com Wed Jul 5 03:47:24 2000 From: crossfire-announce-request at lists.real-time.com (crossfire-announce-request@lists.real-time.com) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] crossfire-announce@lists.real-time.com mailing list reminder Message-ID: <200007050847.e658lOc15188@sprite.real-time.com> This is a reminder of how to unsubscribe or change your configuration for the address "crossfire-list@lists.real-time.com" on the mailing list crossfire-announce. You need to have your password for these things. YOUR crossfire-announce PASSWORD IS: wicky2woo To make changes to your subscription, use the password on your options World Wide Web page: https://mailman.real-time.com/mailman/options/crossfire-announce/crossfire-list@lists.real-time.com You can also make such changes via email - send a message to: crossfire-announce-request@lists.real-time.com with the text "help" in the subject or body, and you will be emailed instructions. Questions or comments? Please send them to crossfire-announce-admin@lists.real-time.com. From frank_mckenney at mindspring.com Wed Jul 5 14:07:49 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] CF 0.95.6 Client discards commands under "load" - feature, not bug References: <200006300328.XAA21076@maynard.mail.mindspring.net> <200006301445.KAA30041@tisch.mail.mindspring.net> Message-ID: <200007051807.OAA02437@maynard.mail.mindspring.net> Reply to message from Mark Wedel on Fri, 30 Jun 2000 20:16:25 -0700: > Times that will consume a lot of bandwidth: > > 1) entering a new map > 2) Stepping on a square with lots of objects on it (piles of sold > stuff in shops > for example, or if you have a narrow hallway and are killing a bunch > of monsters > on the same space) > 3) Picking up that large pile of stuff. I've seen (2) and (3) after some combat in the Hall of Bones in the "Ruins of Euthville" (can't believe it took me six _months_ to get the pun!). A guy can get killed while the server is still sending millio... thousan... hundre... well, anyway, a _lot_ of "you can't pick something up because you're already over your limit" messages. Too bad these can't be combined into one big "You failed to pick up 6,324 lbs of assorted junk because you forgot to eat your Wheaties for breakfast" message. > > Would some of the lurkers out there care to offer some examples of > > "slow", "acceptable", "really snappy", and "probably unplayably slow" > > hardware, specifically with respect to Crossfire 0.95.6? > > Note that load on the server will vary this. A server with 10 active players > certainly has different load than a single player server. > > I would say 32 mb of ram is on the low side in modern standards. > > One thing you can do use use the 'time (or is it times) command. This > displays > tick information - more importantly, how many times it was > not able to complete > all the desired stuff within the 120 ms time > constraint. You will certainly get > some long times, since map > loading will happen in one tick, so that can make for > some very long > ticks here and there. Okay... Hm. Initial logon/movement don't seem as bad as I had epected. Here's what I saw after I restarted the server, started the (X11) client, and logged in: Total time: ticks=256 time=2.489 avg time=9ms max time=420ms min time=-3ms ticks longer than max time (120ms) = 2 (0%) Time last 100 ticks: avg time=11ms max time=420ms min time=-3ms ticks longer than max time (120ms) = 1 (1%) Here are the numbers after leaving my apartment: Total time: ticks=1645 time=11.398 avg time=6ms max time=420ms min time=-3ms ticks longer than max time (120ms) = 4 (0%) Time last 100 ticks: avg time=8ms max time=278ms min time=0ms ticks longer than max time (120ms) = 1 (1%) Then, after triggering the "Run On" problem and slamming myself silly into the outer East Gate (see Bugzilla for details): Total time: ticks=2551 time=13.979 avg time=5ms max time=420ms min time=-3ms ticks longer than max time (120ms) = 6 (0%) Time last 100 ticks: avg time=8ms max time=278ms min time=0ms ticks longer than max time (120ms) = 1 (1%) The numbers _do_ get bigger. Last time I checked, after 36732 ticks (221.821) the longest tick was still only 1914 (2 secs). I may hack the client to report any ticks longer than (say) 500 ms to the "info" window just so I can get a feel for when they occur. > > That is, I know my own system is a bit slow-ish, but I'm new enough to > > Crossfire that I have no sense of what hardware its servers (and > > clients) are running on. If everyone by me now has a 256Mb > > Athlon/P-III > > 600MHz box, my three-hour compilation (I'm slow and pedantic) may only > > be of use to one or two people. > > 3 hour? I would really look at adding some more ram. a 486 dx4-100 > > shouldn't > be that slow. Compiling on a 100 mhz sparc 10 (hypersparc) only took > >about 8 > minutes. On a p3-500, it took about 1 min 45 seconds. Um. Er. Actually, the 486DX4-100 only takes about 20 minutes to build the server (configure & makes), which puts it half the throughput of your Sparc 10. Now, if only I could write _documentation_ that fast (e.g. my "compilation" of information on the command window). Then there are the two Sun3/60s in the basement I never found the time to get running... > > Do you (does anyone) have any idea how often users are actually > > exceeding (for whatever reason) the default command_window seting of > >10? > Just to be clear - I don't think exceeding it is necessarily a bad > thing. > I do at times exceed that when playing. Most often beacause I am > running in > some direction and enter a building or the like, so there > is that brief pause. > I generally find 10 about the right size - > enough so that I can type a few > things in advanced, but not so long > that I get stuck against a wall waiting for > all those movements to > get resolved. I hear what you're saying, and I need to think about it a bit. While I have a current _preference_, that could just be a result of the time I've spent with 0.93.x where _everything_ got stacked up incredibly. I need to really try your "limited window" approach for a bit to give me some experience for an actual "opinion". Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From mwedel at scruznet.com Wed Jul 5 23:19:32 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:19 2005 Subject: [CF List] CF 0.95.6 Client discards commands under "load" - feature, not bug References: <200006300328.XAA21076@maynard.mail.mindspring.net> <200006301445.KAA30041@tisch.mail.mindspring.net> <200007051807.OAA02437@maynard.mail.mindspring.net> Message-ID: <396408D4.CDD52436@scruznet.com> Frank McKenney wrote: > > 2) Stepping on a square with lots of objects on it (piles of sold > > stuff in shops > > for example, or if you have a narrow hallway and are killing a bunch > > of monsters > > on the same space) > > 3) Picking up that large pile of stuff. > > I've seen (2) and (3) after some combat in the Hall of Bones in the > "Ruins of Euthville" (can't believe it took me six _months_ to get the > pun!). A guy can get killed while the server is still sending millio... > thousan... hundre... well, anyway, a _lot_ of "you can't pick > something up because you're already over your limit" messages. Too bad > these can't be combined into one big "You failed to pick up 6,324 lbs of > assorted junk because you forgot to eat your Wheaties for breakfast" > message. Yeah - there isn't a perfect solution. Possible idea are: 1) Have piles fall over to other squares if they get too big. This limits the size of any one pile, but may not work really well in some cases like hte hall of bones where many spaces may have big piles (stuff may end up falling over to be all over the map or the like). 2) Client only sends some number of items on any one space. This complicates things in that it adds complication to get the full stack of items (does the client request it? And if so, then it will probably re-send the initial small stacking) The problem is more that I don't really want to have the client have to keep track of what it sent. One option might be to do something different if the character is running (more likely to happen in combat). Having lags is not nearly as big a deal if the character is safe. For that reason, fixing up delays in pickup is not a high priority (and as actually realistic - it should take some signifcant amount of time to pick up 20 items). But the pickup speed can easily be fixed right now by setting your pickup code appropriately so you don't pick up tons of stuff. > The numbers _do_ get bigger. Last time I checked, after 36732 ticks > (221.821) the longest tick was still only 1914 (2 secs). I may hack the > client to report any ticks longer than (say) 500 ms to the "info" window > just so I can get a feel for when they occur. The times command actually comes from the server. The longest tick time can be sort of meaningless on a single player server - a long map load or anything that blocks the server will create a long tick time. More important in my mind is the last 100 tick stats after doing combat or the like - combat has lots of active objects & updates, and is also the most important in terms of performance. Performance while selling stuff really is not all that important. > Um. Er. Actually, the 486DX4-100 only takes about 20 minutes to build > the server (configure & makes), which puts it half the throughput of > your Sparc 10. Now, if only I could write _documentation_ that fast > (e.g. my "compilation" of information on the command window). > > Then there are the two Sun3/60s in the basement I never found the time > to get running... The 3/60 is really a dog by modern standards (its a 20 mhz 68020). In terms of crossfire, it may be sufficient now to run a black & white client, but xpm display will likely be too slow. From frank_mckenney at mindspring.com Thu Jul 6 18:37:25 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Character gains invisible weight. Diet possibe? (CF 0.95.6) Message-ID: <200007062236.SAA26051@blount.mail.mindspring.net> My character has apparently been consuming too many "invisible" calories and has gained 70 pounds. He _definitely_ needs to go on some kind of diet... but of what? More specifically, following a 'dropall (in my apartment), my character's 'Inventory:' window shows him as carrying 70.0 pounds, but the only item _in_ the inventory is a single (locked) "a Gate Pass" whose weight is listed as 0.0. Any ideas? Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Thu Jul 6 18:37:26 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] png images References: <20000703004615.21874.qmail@web215.mail.yahoo.com> <3961905E.446FB09F@scruznet.com> Message-ID: <200007062237.SAA32685@blount.mail.mindspring.net> Norbert Irmer wrote: > I think it would do no harm to allow the number of colors to be > unlimited, > > Since you can setup a true color palette even on a 8 bit display, for > example > by using 3 bits for red, 3 bits for green, and 2 bits for blue. > > (I did this a few years ago when using a self written opengl renderer on > an old > sun workstation with 8 bit display, and the results were quite > acceptable) > > Then the game would still still be playable on old 8 bit displays, and > the > artists have any freedom they want. Norbert, Every freedom brings its own set of restrictions (;-). I worked with a local graphics company a few years back when reasonably- priced 8-bit color was a relatively new thing: I contributed some technical expertise, and they knew "what looked good". It was a definite "learning experience" (;-). If one's normal working environment is "lotsa colors" (e.g. 24-bit, 8:8:8 color) it can be extremely difficult to create _good_ 256 color or 3:3:2 color images. It's all to easy to create a stunning 8:8:8 color image whose impact turns around the use of subtle shadings; when these are converted ("butchered") to fit a palette (or the fixed palette of 3:3:2 color) those shadings are often lost. What was an amazing 8:8:8 red robe becomes a blob with perhaps two shades of red. For what you're suggesting, you'd have to view your images in both modes, then go back and tweak the high-color images, and repeat this process until _both_ sets looked good. The graphics people usually found it was a lot less work to create their images in 256-color or 3:3:2 color mode to start with. Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From jhantin at derringer.net Thu Jul 6 19:45:18 2000 From: jhantin at derringer.net (Jeffrey Hantin) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Character gains invisible weight. Diet possibe? (CF 0.95.6) In-Reply-To: <200007062236.SAA26051@blount.mail.mindspring.net> References: <200007062236.SAA26051@blount.mail.mindspring.net> Message-ID: <20000707.451800@bullet.derringer.net> > My character has apparently been consuming too many "invisible" calories > and has gained 70 pounds. He _definitely_ needs to go on some kind of > diet... but of what? > More specifically, following a 'dropall (in my apartment), my > character's 'Inventory:' window shows him as carrying 70.0 pounds, but > the only item _in_ the inventory is a single (locked) "a Gate Pass" > whose weight is listed as 0.0. That is actually your character's body weight. 70 kg (154 lb) is about right for human characters, assuming they don't have beer bellies. :-) By contrast, a fireborn weighs a mere 15 kg. However, to clear up confusion, perhaps the client needs to be sent just the carried weight rather than the total weight? > Any ideas? On a side note, maybe a unit conversion facility would help keep folks from being confused-- and help keep item weights reasonable by not confusing archetype writers (a lot of stuff is ridiculously heavy). Crossfire uses the metric system, which seems to confuse folks in the States who aren't expecting it. :-) From jhantin at derringer.net Thu Jul 6 19:55:05 2000 From: jhantin at derringer.net (Jeffrey Hantin) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] png images In-Reply-To: <200007062237.SAA32685@blount.mail.mindspring.net> References: <20000703004615.21874.qmail@web215.mail.yahoo.com> <3961905E.446FB09F@scruznet.com> <200007062237.SAA32685@blount.mail.mindspring.net> Message-ID: <20000707.550500@bullet.derringer.net> > For what you're suggesting, you'd have to view your images in both > modes, then go back and tweak the high-color images, and repeat this > process until _both_ sets looked good. The graphics people usually > found it was a lot less work to create their images in 256-color or > 3:3:2 color mode to start with. My usual technique is to draw an icon image in 4-bit RGBI or 3:3:2 true-color to begin with, using dithering and pointillism to generate the subtle shading in that mode, then copy it up to a higher mode and replace the dotty stuff with true shading. That's still sort of double work though. From norbert.irmer at heim9.tu-clausthal.de Thu Jul 6 19:16:25 2000 From: norbert.irmer at heim9.tu-clausthal.de (Norbert Irmer) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] png images References: <20000703004615.21874.qmail@web215.mail.yahoo.com> <3961905E.446FB09F@scruznet.com> <200007062237.SAA32685@blount.mail.mindspring.net> Message-ID: <39652159.CFD9CC37@heim9.tu-clausthal.de> Frank McKenney wrote: > Every freedom brings its own set of restrictions (;-). > > I worked with a local graphics company a few years back when reasonably- > priced 8-bit color was a relatively new thing: I contributed some > technical expertise, and they knew "what looked good". It was a > definite "learning experience" (;-). > > If one's normal working environment is "lotsa colors" (e.g. 24-bit, > 8:8:8 color) it can be extremely difficult to create _good_ 256 color or > 3:3:2 color images. It's all to easy to create a stunning 8:8:8 color > image whose impact turns around the use of subtle shadings; when these > are converted ("butchered") to fit a palette (or the fixed palette of > 3:3:2 color) those shadings are often lost. What was an amazing 8:8:8 > red robe becomes a blob with perhaps two shades of red. > > For what you're suggesting, you'd have to view your images in both > modes, then go back and tweak the high-color images, and repeat this > process until _both_ sets looked good. The graphics people usually > found it was a lot less work to create their images in 256-color or > 3:3:2 color mode to start with. > Hi, I was thinking at the future. In a few years nobody will use 8 bit displays anymore. So why spend much time on creating fine-tuned images for 8-bit color palettes - since these images, as good as they may be, could look even better on 24 bit displays when done in 8:8:8. Don't misunderstand me, I like the current xpm graphics very much, and i didn't meant to offend someone. But i think, if there must be new graphics, then better in 8:8:8 right from the beginning. Or at least, the original high color graphics should be kept somewhere in the CVS archive, when they are reduced to 8 bit. Norbert From norbert.irmer at heim9.tu-clausthal.de Thu Jul 6 19:35:33 2000 From: norbert.irmer at heim9.tu-clausthal.de (Norbert Irmer) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] png images References: <20000703004615.21874.qmail@web215.mail.yahoo.com> <3961905E.446FB09F@scruznet.com> <200007062237.SAA32685@blount.mail.mindspring.net> <20000707.550500@bullet.derringer.net> Message-ID: <396525D5.B1B8AD40@heim9.tu-clausthal.de> Jeffrey Hantin wrote: > My usual technique is to draw an icon image in 4-bit RGBI or 3:3:2 > true-color to begin with, using dithering and pointillism to generate > the subtle shading in that mode, then copy it up to a higher mode and > replace the dotty stuff with true shading. That's still sort of > double work though. > Ok, you (oratory-level=20:) convinced me. If it is easier to create good looking high color graphics from low ones then vice versa, it is really the best to do first the low color graphics. Norbert From philb at csua.berkeley.edu Wed Jul 5 16:47:24 2000 From: philb at csua.berkeley.edu (Philip Brown) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] [CF Announce] updated java client available Message-ID: <200007052147.OAA12313@soda.csua.Berkeley.edu> The java client has been reworked a little, so that it should be more reliable for non-solaris JVMs. And more forgiving about which VERSION of JVM you are runnig, too. It should now work on Mac, PC, and UNIX. it aint perfect, but it's available, at least ;-) http://www.bolthole.com/jcrossclient/ if you are interested. Be sure to download the "beta" version _______________________________________________ crossfire-announce mailing list crossfire-announce@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-announce From taporg at yahoo.com Sat Jul 8 18:16:08 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Re: png images Message-ID: <20000708231608.20543.qmail@web217.mail.yahoo.com> Mark Wedel wrote: > > Clearly, I'm biased on the subject, because I prefer > > to draw without color restrictions. And while it may > > take more skill to do a good job on low-color image, > > I believe that well-done high color images can look > > noticably better than ones with the existing colorset. > > Certainly it is easier to do anything if there is no restrictions. Well, I think the reason is better than just removing restrictions. My personal style, for instance, would have me drawing the images in highcolor regardless, and if necessary, quantizing to a palette. But furthermore, I do believe that, insofar as visual appeal is relevant, highcolor images on average look better than 8 bit images. For me, at least, the difference is perceptible. Anyways, I've done some experimenting, with the following results: ftp://ftp.ifi.uio.no/pub/crossfire/incoming/images.png In the image above, the first column contains the original highcolor tiles. The second column contains tiles quantized to the crossfire palette that you've provided. The third column is quantized to 3/3/2 RGB, logarithmically allocated, and the fourth column is also 3/3/2 RGB, but linearly allocated. Some of the tiles have "holes" in them, but that's only because the quantizing program mistakenly quantized to the transparent color, so I wouldn't worry about it. Anyways, I think the linear 3/3/2 is garbage compared to the others, So I won't even bother considering it. Both the crossfire palette and the logarithmic 3/3/2 are fine on some images, but they have problems with others. The crossfire palette, for instance does a poor job of the mage's purple, as well as the dark browns of the viking's shield. The logarithmic palette has problems with blues and bright greens, which I suppose is no surprise given only four levels of blue. > But my own feeling is that why break something that doesn't need > to be broken. I'd like to clarify what exactly would get broken here. First of all, I'm assuming that the server is independent of color depth color, because it would simply be silly otherwise. Also, in my cursory examination of the client code (at least the gtk version), it didn't seem that anything within the code would limit the display to being 8 bit. Thus, if I am not mistaken, the only thing that would be broken by the inclusion of full-color images would be the platforms that run on 8-bit displays, correct? And even in cases where the display is 8-bit, the program would still function, although the images with extra color would be quantized to the local palette, right? Which, if necessary, could be set early if the server were to send a pixmap containing its ideal colorset early on... > Someone actually mentioned that he thought it > worked better for the images to be a little more iconic than photo > realistic. This I can understand, based on the idea that if the majority of the tileset is semi-realistic, it becomes easier to notice the tiles that are inconsistant. But then, given that part of the tileset has already been made semi-realistic, and that good photo realism isn't likely at 32x32 no matter how many colors are allowed, I'd say that it's a moot point. > And I think most people will agree that even with the > limited color set used for the png's, they still look very > nice. No disagreement here. And I think that you'll notice in the test image listed above, some of the tiles look pretty much the same when quantized down. However, some of them don't. And I'm not sure that it's reasonable for artists to always have to check if the color scheme that they want to use is well developed. To take the argument a step further, I think it's necessary for the default palette to do a good job with common stuff, such as walls, characters, and common monsters, which I think it does. Beyond that, however, I would also say it seems acceptable if an artist is to make a more exotic monster look good on a full color display, and for users with 8 bit displays to see a quantized version which is "good enough". -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Sat Jul 8 18:16:43 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Re: png images Message-ID: <20000708231643.15358.qmail@web208.mail.yahoo.com> Norbert Irmer wrote: > But i think, if there must be new graphics, then better in 8:8:8 > right from the beginning. Or at least, the original high color > graphics should be kept somewhere in the CVS archive, when they are > reduced to 8 bit. I was even thinking that it wouldn't be a bad idea if the CVS version contained full color images, like you suggest, along with a script in the top level directory, called from a makefile if configured to do so, that would convert all of the images in the tree to a single palette. As a side note, I do tend to keep my individual images saved as 8-bit pngs, simply because the file size is smaller than for 24 bit pngs. Doing so makes sense because even for a 24 bit image set, any individual 32x32 image really doesn't need more than 256 colors. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Sat Jul 8 18:34:19 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Re: png images Message-ID: <20000708233419.13154.qmail@web216.mail.yahoo.com> scott wrote: > CF is not a 3D imersion game where limited colors interfer with > the desired realism. It is an overhead map with objects on squares. > Rings are almost as large as players and so on. The goal is not > realism, but recognition. The question is whether the player can > easily see and identify the item. I think that given that recognition has already been completely achieved, and that full color images can be easier to create and can look better than 8 bit images (see my other mail for a link to an image which provides a basis for comparison), the question is whether full color support can be added without undue penalty. I think that the nature of the penalty is somewhat less than obvious. I don't believe that there's any programatical penalty or image size penalty (most of the tiles would probably be saved as 8 bit images anyways). I even believe that so long as the images can be quantized by the client and still look reasonable (as I mentioned in my other mail, I believe that it's currently possible but not completely sure), the 256 color workstation audience would not be sacrificed. However, I think that if the graphics are made more salient, the target audience may shift subtly, from players who enjoy roguelike games and who find multiplayer and graphics a bonus, to players who would otherwise be playing something like Diablo II, and who might consider crossfire somewhat inferior. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Sat Jul 8 22:56:10 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Re: png images References: <20000708231608.20543.qmail@web217.mail.yahoo.com> Message-ID: <3967F7DA.DF31DBC5@scruznet.com> Jonathan Taporg wrote: > > Anyways, I've done some experimenting, with the following results: > ftp://ftp.ifi.uio.no/pub/crossfire/incoming/images.png > In the image above, the first column contains the original highcolor > tiles. The second column contains tiles quantized to the crossfire > palette that you've provided. The third column is quantized to > 3/3/2 RGB, logarithmically allocated, and the fourth column is also > 3/3/2 RGB, but linearly allocated. Some of the tiles have "holes" > in them, but that's only because the quantizing program mistakenly > quantized to the transparent color, so I wouldn't worry about it. I don't know if that link better proves your case of needing 24 bit palette, or proves the case that the current colors are fine. I opened it up, and generally find it very difficult to notice any difference between the columns. And this is a situation where I am taking my leisure and putting my nose 6" from the screen. This is not something people are likely to do while actually playing the game. Maybe others can look at this and give their opinion on the quality to remove factors of monitor or display card. > > Anyways, I think the linear 3/3/2 is garbage compared to the others, > So I won't even bother considering it. Both the crossfire palette > and > the logarithmic 3/3/2 are fine on some images, but they have problems > with others. The crossfire palette, for instance does a poor job of > the mage's purple, as well as the dark browns of the viking's shield. Note that the crossfire pallette is not set in stone. If you find large holes in the pallette, in can be expanded. But I will note that you also get a different behaviour if you start with all the colors and try to reduce down to the crossfire pallette compared to using the crossfire pallete for the initial drawing. In any case where you start with an infinite pallette, there will be holes in a reduced pallette you can not map against. but if instead you start with a reduced pallette, you may say 'well, there is no really good purple, so maybe I'll use some other color for that' > I'd like to clarify what exactly would get broken here. First of > all, > I'm assuming that the server is independent of color depth color, > because it would simply be silly otherwise. Also, in my cursory > examination of the client code (at least the gtk version), it didn't > seem that anything within the code would limit the display to > being 8 bit. Thus, if I am not mistaken, the only thing that would > be broken by the inclusion of full-color images would be the > platforms that run on 8-bit displays, correct? And even in cases > where the display is 8-bit, the program would still function, > although > the images with extra color would be quantized to the local palette, > right? Which, if necessary, could be set early if the server were > to send a pixmap containing its ideal colorset early on... Server does not care about graphics. You could send windows pict files for all it cares. I'm not sure what imlib does when you try to load an image which it can't allocate colors for (like on an 8 bit display). I can think of two behaviours: 1) Generates an error which I don't beleive the client currently catches, which would crash the client. 2) Does some color matching scheme against colors already allocated. Note that if all the images are true color, this can end up being really terrible, as the first couple dozen images could fill the entire 256 color pallette, and all subsequent loads would match against those colors. Since the first bunch of images are from the map, the characters starting location would largely dictacte the color balance. For example, if the player resumed underground, it is very possible that color map will get allocated a lots of greys and browns, so when you head outdoors, there may be only 1 or 2 greens allocated, so all the forest & plants get allocated to that one color. In either case, better support is needed in the client. One method is to allocated a preset colormap to match against. either the 8/8/4 (number of colors) method of the 6/6/6 color method. Neither produces really good results, and may not be all that representative. And from past experience with using 'xv' in a 6x6x6 color cube for 24 bit images, the results are really terrible. > No disagreement here. And I think that you'll notice in the > test image listed above, some of the tiles look pretty much the > same when quantized down. However, some of them don't. And I'm > not sure that it's reasonable for artists to always have to check > if the color scheme that they want to use is well developed. Crossfire has been doing it that way for the past 7 or 8 years. This may not be the right thing to do, but it has worked out. > > To take the argument a step further, I think it's necessary for the > default palette to do a good job with common stuff, such as walls, > characters, and common monsters, which I think it does. Beyond that, > however, I would also say it seems acceptable if an artist is to make > a more exotic monster look good on a full color display, and for > users with 8 bit displays to see a quantized version which is > "good enough". I would be curious to see what the true color does to the actual image sizes themselves. I think that is also a consideration, as there is also a tradeoff between nicer looking images and the increased space & bandwidth they cause. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:20 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:21 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:22 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From leaf at real-time.com Mon Jul 10 12:06:44 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Autosaving Message-ID: Here is a message that was sent to me directly, please cc: jstsgy@yahoo.com since I don't think they are subscribed to the mailing list. ---------- Forwarded message ---------- Date: Sat, 8 Jul 2000 20:08:57 -0500 Reply-To: jstsgy@yahoo.com This is a suggestion for crossfire: I think the system reboot needs to autosave every character right before resetting. I just lost everything I was carrying after taking it from my apartment. The game reset and loaded my character to right before I picked up the stuff. Since the apartment does not reset, the stuff was no longer on the ground. This really needs to be changed. From tanner at real-time.com Mon Jul 10 12:45:43 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Mail looping Message-ID: <20000710124543.I31345@real-time.com> Is everyone else getting the mail loop? First, It looks like Mailman cannot detect mail loops. I will submit a bug report. Second, someone subscribe an email address to the list which automatically posts/forwards BACK to the list, thus a mail loop. Sorry for all the junk in your inbox. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From erik at subnett.no Mon Jul 10 15:44:00 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Autosaving In-Reply-To: Message-ID: On Mon, 10 Jul 2000, Rick Tanner wrote: > Here is a message that was sent to me directly, please cc: > jstsgy@yahoo.com since I don't think they are subscribed to the mailing > list. Am I the only one who got around 10 copies of this one? ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From tanner at real-time.com Mon Jul 10 13:17:24 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Testing Message-ID: <20000710131724.M31345@real-time.com> Does this loop? -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Tue Jul 11 00:11:03 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Testing for Looping Message-ID: <20000711001103.B5467@real-time.com> Testing for looping. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Tue Jul 11 00:21:29 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Mail looping Message-ID: <20000711002129.C5467@real-time.com> Testing mail looking. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Tue Jul 11 00:21:29 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Mail looping Message-ID: <20000711002129.C5467@real-time.com> Testing mail looking. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Tue Jul 11 00:21:29 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Mail looping Message-ID: <20000711002129.C5467@real-time.com> Testing mail looking. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Tue Jul 11 00:21:29 2000 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Mail looping Message-ID: <20000711002129.C5467@real-time.com> Testing mail looking. -- Bob Tanner | Phone : (612)943-8700 http://www.mn-linux.org | Fax : (612)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:23 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:24 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:25 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:26 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:26 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:26 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:26 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:26 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:26 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:26 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:27 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:27 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:27 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:27 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:27 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:27 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:27 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:27 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:27 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:28 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:29 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:30 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:31 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:32 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:33 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From taporg at yahoo.com Wed Jul 12 01:25:26 2000 From: taporg at yahoo.com (Jonathan Taporg) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] Re: png images Message-ID: <20000712062527.10966.qmail@web216.mail.yahoo.com> Mark Wedel wrote: > I don't know if that link better proves your case of needing 24 bit > palette, orproves the case that the current colors are fine. Well, if nothing else, it means that it's a fair sample :) > I opened it up, and generally find it very difficult to notice any > difference between the columns. And this is a situation where I am > taking my leisure and putting my nose 6" from the screen. This is > not something people are likely to do while actually playing the > game. Maybe others can look at this and give their opinion on the > quality to remove factors of monitor or display card. Maybe, in that case, I'm just more sensitive to the difference. And I'll grant you that maybe it is only for me that considers the higher color graphics better. But I think that we can agree that, while there may not alone justify switching, I think that there is enough evidence that a reason to allow full color is not nonexistant. Which is a relevant point, because ... > I'm not sure what imlib does when you try to load an image which it > can't allocate colors for (like on an 8 bit display). I can think > of two behaviours: I made a point of checking what imlib does. On 8-bit displays, the loaded images are automatically dithered to a pre-defined palette of common colors. Furthermore, 8-bit imlib does not allocate a private colormap, but merely takes whichever colors it can get. To test it, I ran the client in 8-bit mode, and many of the images were indeed dithered and looked different than under 24 bit mode. Thus, for the GTK client, at least, it doesn't really make a difference if the images are allowed to be 24 bit. I'm not sure about the other clients, though, ... once again, you'd probably know better than me. > I would be curious to see what the true color does to the actual > image sizes themselves. I think that is also a consideration, as > there is also a tradeoff between nicer looking images and the > increased space & bandwidth they cause. The beauty is, while the entire color space would be 24 bit, 256 colors should be sufficent for any single 32x32 image, so images could still be saved palettized. There would be no size increase. -j __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From mwedel at scruznet.com Wed Jul 12 02:13:43 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] Re: png images References: <20000712062527.10966.qmail@web216.mail.yahoo.com> Message-ID: <396C1AA7.9A8948ED@scruznet.com> Jonathan Taporg wrote: > > I opened it up, and generally find it very difficult to notice any > > difference between the columns. And this is a situation where I am > > taking my leisure and putting my nose 6" from the screen. This is > > not something people are likely to do while actually playing the > > game. Maybe others can look at this and give their opinion on the > > quality to remove factors of monitor or display card. > > Maybe, in that case, I'm just more sensitive to the difference. > And I'll grant you that maybe it is only for me that considers the > higher color graphics better. But I think that we can agree that, > while there may not alone justify switching, I think that there is > enough evidence that a reason to allow full color is not > nonexistant. I certainly find it is the case that if you made the change, you are more aware of the changes. So I could certainly see you being more sensitive to changes you have made to the images (since you know what changes you have made) you will notice them more. > > I made a point of checking what imlib does. On 8-bit displays, the > loaded images are automatically dithered to a pre-defined palette of > common colors. Furthermore, 8-bit imlib does not allocate a private > colormap, but merely takes whichever colors it can get. To test it, > I ran the client in 8-bit mode, and many of the images were indeed > dithered and looked different than under 24 bit mode. Thus, for the > GTK client, at least, it doesn't really make a difference if the > images are allowed to be 24 bit. I'm not sure about the other > clients, though, ... once again, you'd probably know better than me. I don't know what the java and windows client do (or will do as I don't know if they support png right now) in those cases. Do you know if imlib allocates a preset bunch of colors or just matches against other colors already allocated in the color map? Depending on what it does, they effects will change as more images become truecolor. If for example it allocates a bunch of colors, that works fine. If instead is allocates colors and does color matching (and if it can't match, then dither), then as more image become truecolor, the more problems you have with image quality. As described in my previous example, you could get a case where the first couple images (if all are truecolor) consume the entire colorspace. Right now, just by pure luck you may get a representative color map since most of the images use the crossfire representative color set, and in a sense, that pre-seeds the colormap. Also, you did not say how the dithered (by imlib) truecolor image compares to a standard image as we currently have it. Is the result of imlib worse than what we currently get with the images we have? As a sidenote, at some point, I would really like to get rid of imlib simply because it is buggy, adds additional dependancies, and has lots of extra overhead that is not really needed. I would really like something like the Xpm library for for png - a simple library that reads a png and converts it to a X pixmap without having to save the data to a file. Unfortunately, png still seems to be in its infancy in terms of library support (even the referance png library doesn't seem to have an operation to work on buffers, but instead wants an actual file to work on, which seems really lame to me) > The beauty is, while the entire color space would be 24 bit, 256 > colors should be sufficent for any single 32x32 image, so images > could still be saved palettized. There would be no size increase. I don't know much about the png structure, but I would note that right now, if it supports a 4 bit image, that works fine for the current images we have. If you go to 256 (or actually, anything above 128), you are now an 8 bit image, and have doubled the space for the image. And certainly each color takes some number of bytes. The easiest thing to do is compare the image sizes of some before and after images you have done and see the size difference. That is a much more accurate way of trying to do it than figure out what png will do. From frank_mckenney at mindspring.com Wed Jul 12 15:37:44 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CF 0.95.6 World Map linkage errors (lost-at-sea HOWTO) Message-ID: <200007121937.PAA21102@tisch.mail.mindspring.net> Note: I posted this at Bugzilla, but I'm sending a copy to The List on the assumption that not every Crossfire player carefully tracks everything posted there. The maps shipped with Crossfire 0.95.6 have at least two linkage errors. One is nasty, but hard to hit, and the second, while easier to run into, appears to be only a minor irritation. Lost At Sea Warning: Do not try this unless your character knows "word of recall" or you have a "word of recall" scroll. Exit Navar to the countryside, and position your character in the SW of the four squares representing Navar. From here, go 2SW, 1S, and then 1N. You will notice a change in your environment: You're on map world_c2 at 20,5, a spot that's usually hard to get to, and there's "nothing" north of you. Now don your bathing trunks and go 5S. You appear to be completely lost, but (as you quickly determine from the 'mapinfo command) you are actually on map world_c1 at 20,0, and from that square there _is_ no land in sight. Countryside "hiccups" Warning: I did not encounter any serious problems playing around in this generally inaccessible map section, but that doesn't mean there's nothing nasty there. From John.Cater at monash.edu.au Wed Jul 12 19:38:09 2000 From: John.Cater at monash.edu.au (John Cater) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CF 0.95.6 World Map linkage errors (lost-at-sea HOWTO) References: <200007121937.PAA21102@tisch.mail.mindspring.net> Message-ID: <396D0F71.41C6@monash.edu.au> > The maps shipped with Crossfire 0.95.6 have at least two linkage errors. I have fixed the slaying fields of a couple of exits, which seems to fix these problems for me. The changes are on the cvs tree - if anyone wants me to mail them the "fixed" versions, just give me a tinkle. Johnc From mwedel at scruznet.com Wed Jul 12 22:03:11 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CF 0.95.6 World Map linkage errors (lost-at-sea HOWTO) References: <200007121937.PAA21102@tisch.mail.mindspring.net> <396D0F71.41C6@monash.edu.au> Message-ID: <396D316F.23476DA8@scruznet.com> I'm not certain, but this may be a contributing factor: Maps can have a default entry point - this is very seldom used since almost all exits specifically have the entry point for the destination map set. By default, I think these standard destination coordinates are set to 2,2. In the case of the west world maps, this is almost certainly in the ocean someplace. If not already, these destination values should probably be set to more sensical values. You can see these in the editor by viewing the map attributes. From frank_mckenney at mindspring.com Thu Jul 13 22:58:48 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] How many blue mushrooms? (CF 0.95.6 Baron quest) Message-ID: <200007140258.WAA09080@smtp10.atl.mindspring.net> If I sound a little vague here, it's mostly because I'm trying to avoid spoiling this quest for any new players. I undertook the Baronial quest, the Search for The Blue Mushroom. I followed the clues and fought my way past _swarms_ of assorted monsters (I was not nibbled to death by ducks, but I may have just missed that part of the quest (;-)). I found a Blue Mushroom, and I brought it back to Scorn. Unfortunately, when I drop _my_ Blue Mushroom on the required pentagram, nothing happens. This kind of takes the fun out of questing, since (I assume) I can't advance in rank until I become a Baron. I can think of two possibilities (I'm sure others exist): 1) It's a bug, and I'm out of luck. 1a) It's a bug, and was fixed in the CVS drop as of xxJul00. 2) I've been successfully "faked out" by an Evil Counterfeit Blue Mushroom, and I need to go back and look harder for the One Holy True-Blue Mushroom ("They got _rooms_ for that stuff?" (;-)) I _thought_ I had read a discussion on this in the mailing list, but the official list archive search engine turns up very little for 'mushroom' or 'baron'. Looks like I was mistaken. Server is an "updated" 0.95.6, CVS drop as of 04Jul00. Thanks... Frank Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From leaf at real-time.com Thu Jul 13 23:30:43 2000 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] How many blue mushrooms? (CF 0.95.6 Baron quest) In-Reply-To: <200007140258.WAA09080@smtp10.atl.mindspring.net> Message-ID: On Thu, 13 Jul 2000, Frank McKenney wrote: > I _thought_ I had read a discussion on this in the mailing list, but the > official list archive search engine turns up very little for 'mushroom' > or 'baron'. Looks like I was mistaken. Hmm, looks like the Search Engine is not archiving the new mailing list. I will look into this. I think the post you are looking for is: http://mailman.real-time.com/pipermail/crossfire-list/2000-June/000020.html - Rick Tanner leaf@real-time.com From Kimmo.Hoikka at Digia.com Fri Jul 14 07:10:07 2000 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] How many blue mushrooms? (CF 0.95.6 Baron quest) References: <200007140258.WAA09080@smtp10.atl.mindspring.net> Message-ID: <396F031F.E7BB93C9@Digia.com> Frank McKenney wrote: > If I sound a little vague here, it's mostly because I'm trying to avoid > spoiling this quest for any new players. > > I undertook the Baronial quest, the Search for The Blue Mushroom. I > followed the clues and fought my way past _swarms_ of assorted monsters > (I was not nibbled to death by ducks, but I may have just missed that > part of the quest (;-)). I found a Blue Mushroom, and I brought it back > to Scorn. > > Unfortunately, when I drop _my_ Blue Mushroom on the required pentagram, > nothing happens. This kind of takes the fun out of questing, since (I > assume) I can't advance in rank until I become a Baron. > > I can think of two possibilities (I'm sure others exist): > > 1) It's a bug, and I'm out of luck. > > 1a) It's a bug, and was fixed in the CVS drop as of xxJul00. > > 2) I've been successfully "faked out" by an Evil Counterfeit Blue > Mushroom, and I need to go back and look harder for the One Holy > True-Blue Mushroom ("They got _rooms_ for that stuff?" (;-)) > > I _thought_ I had read a discussion on this in the mailing list, but the > official list archive search engine turns up very little for 'mushroom' > or 'baron'. Looks like I was mistaken. It was me who wrote about this bug a while ago (28.6.) and the answer is 1. it is a bug as Peter admitted after doing some testing :) I hope it will be fixed soon though. -- ___ <@,@> Kimmo Hoikka - www.hoikka.com [`-'] Pellonm?enraitti 3 as 8, 53850 Lpr -"-"- +358(0)40 738 0747 From peterm at tesla.EECS.Berkeley.EDU Mon Jul 17 00:52:02 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] How many blue mushrooms? (CF 0.95.6 Baron quest) In-Reply-To: Your message of "Fri, 14 Jul 2000 15:10:07 +0300." <396F031F.E7BB93C9@Digia.com> Message-ID: <200007170552.WAA17285@tesla.EECS.Berkeley.EDU> > Frank McKenney wrote: > > It was me who wrote about this bug a while ago (28.6.) and the answer is 1. > it is a bug as Peter admitted after doing some testing :) I hope it will be > fixed soon though. Yeah it was a bug. I thought I had fixed it already, though: it should be in the CVS repository right now. The latest release will have the but still, though. PeterM From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:34 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From frank_mckenney at mindspring.com Wed Jul 19 23:32:21 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:35 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? Message-ID: <200007200331.XAA31504@granger.mail.mindspring.net> I tried to pick up a fresh copy of the server code this evening from the CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, while that host name worked just fine earlier in the month, I can't seem to connect to it. Is anyone else seeing this problem? Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From erik at subnett.no Thu Jul 20 05:03:03 2000 From: erik at subnett.no (Erik Gjertsen) Date: Thu Jan 13 18:03:35 2005 Subject: [CF List] CVS snapshot mirror at crossfire.futt.org down? In-Reply-To: <200007200331.XAA31504@granger.mail.mindspring.net> Message-ID: On Wed, 19 Jul 2000, Frank McKenney wrote: > I tried to pick up a fresh copy of the server code this evening from the > CVS snapshot mirror site Erik Gjertsen kindly set up. Unfortunately, > while that host name worked just fine earlier in the month, I can't seem > to connect to it. It should be working now. Enitel (former Telia) who is our upstream internet provider, had some problems yesterday with one of their ATM lines, so most of their customers in western Norway were without connection for the better part of the day (and night...). I am sorry about this, the problem should be solved now. ---[ erik gjertsen ]--------- - - - - - ---[ PGP: http://erik.subnett.no/pgp.txt ]- - - - From frank_mckenney at mindspring.com Mon Jul 24 20:28:44 2000 From: frank_mckenney at mindspring.com (Frank McKenney) Date: Thu Jan 13 18:03:35 2005 Subject: [CF List] Server crashes during Dragon Quest (CVS 07/21) Message-ID: <200007250028.UAA07840@maynard.mail.mindspring.net> Server: CVS 07/21/00 snapshot Intel x86 PC, 486DX4-100, 32 Mb RAM, SuSE Linux 6.4 Client: CVS 07/21/00 snapshot (X11 client) (same machine) I have had my server die twice now at level three on the Dragon Quest. Both times the server logged a "Trying to remove removed object." message (details below). Following the first failure, I restarted the client and server and wandered back down into the dungeon. The server did not die this time, but I was unable to go to level three: ---- xsize 32 Ysize 23 wallstyle cave2 floorstyle stones2 monsterstyle dragon decorstyle craters exitstyle sstair final_map /peterm/quests/dragonquest2 dungeon_level 4 dungeon_depth 12 orientation 1 origin_x 16 origin_y 9 The /random/0000000000000026 is closed. ---- I left the server running and ignored it for a couple of days. This evening when I tried again, the server crashed again. Any suggestions? Anyone else seeing this? Failure #1 ---------- --snip-- Couldn't find archetype rough_2_1_1 Couldn't find archetype rough_2_1_1 Couldn't find archetype rough_2_1_1 SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... Saving map /styles/floorstyles/outdoor_lush --snip-- Saving map /styles/trapstyles/traps Trying to remove removed object. arch trap_blades name Blades trap msg You set off a Blades trap! endmsg face blades.111 animation trap_blades is_animated 0 Cha 20 hp 1 dam 90 speed 1.000000 speed_left 0.900000 level 1 type 154 attacktype 1 invisible 1 no_pick 1 walk_on 1 end ---------- Failure #2 ---------- --snip-- Saving map /styles/trapstyles/traps Trying to remove removed object. arch rune_poison_cloud name Rune of Poison Cloud slaying poison cloud msg You detonate a Rune of Poison Cloud! endmsg face rune_pcloud.111 animation rune_poison_cloud is_animated 0 Cha 20 hp 1 speed 1.000000 level 1 type 154 attacktype 6 invisible 1 no_pick 1 walk_on 1 end ---------- Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From mwedel at scruznet.com Wed Jul 26 01:25:57 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:35 2005 Subject: [CF List] Server crashes during Dragon Quest (CVS 07/21) References: <200007250028.UAA07840@maynard.mail.mindspring.net> Message-ID: <397E8475.DC6A3C7A@scruznet.com> Frank McKenney wrote: > Failure #1 > ---------- > --snip-- > Couldn't find archetype rough_2_1_1 > Couldn't find archetype rough_2_1_1 > Couldn't find archetype rough_2_1_1 That object does not appear to exist. I think it should in fact be a rough_wall_2_1_1 - I don't see rough_2_1_1 being used in any of the map files (include the styles), so my initial guess would be that the random_map code is improperly truncating the name. Since I see the SIGSEGV right after that, my guess is that the removing a removed object is just an after effect. Looking at random_map/wall.c (around line 170), it does appear that the code there does not deal with wall codes that may have an underscore in the name. I'm not familiar specifically what that function does. I do note that all the styles/wall files are a format of ..._0 (ie, rough_wall_0, gwall_0, etc), so it would seem possible that maybe that fact could be used in truncating the wall name. The other possibilities I could think of in that function is to check the next character - if a number, presume that is the underscore we want to stop at, if another letter, presume it is part of the arch basename. Peter - you probably know more about that section of code than I do. I don't know if the editor or any other functions may have similar assumptions about the autojoining walls or not. If so, either those need to be fixed or perhaps we should rename rough_wall to be roughwall instead (I don't know how many maps may be using the first form that would require updating) From mwedel at scruznet.com Wed Jul 26 01:40:33 2000 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:35 2005 Subject: [CF List] Server crashes during Dragon Quest (CVS 07/21) References: <200007250028.UAA07840@maynard.mail.mindspring.net> <397E8475.DC6A3C7A@scruznet.com> Message-ID: <397E87E1.82C224C7@scruznet.com> Mark Wedel wrote: > I don't know if the editor or any other functions may have similar assumptions > about the autojoining walls or not. If so, either those need to be fixed or > perhaps we should rename rough_wall to be roughwall instead (I don't know how > many maps may be using the first form that would require updating) I take that part back - it appers that both rough_wall and roughwall exist, and are the same objects except for the name. We should really settle on one of get rid of the other. According the the map_info script, the non underscore one (roughwall) is not currently being used in any official maps. From peterm at tesla.EECS.Berkeley.EDU Wed Jul 26 13:45:03 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:35 2005 Subject: [CF List] Server crashes during Dragon Quest (CVS 07/21) In-Reply-To: Your message of "Tue, 25 Jul 2000 23:40:33 PDT." <397E87E1.82C224C7@scruznet.com> Message-ID: <200007261845.LAA31842@tesla.EECS.Berkeley.EDU> > Mark Wedel wrote: > I take that part back - it appers that both rough_wall and roughwall exist, >and > are the same objects except for the name. We should really settle on one of >get > rid of the other. According the the map_info script, the non underscore one > (roughwall) is not currently being used in any official maps. I'd like to keep the "roughwall" version, please, on the grounds that it simplifies my random map autojoining code considerably. Having both makes it unnecessary to fix all the existing maps. PeterM From peterm at tesla.EECS.Berkeley.EDU Wed Jul 26 22:50:13 2000 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:35 2005 Subject: [CF List] Server crashes during Dragon Quest (CVS 07/21) In-Reply-To: Your message of "Mon, 24 Jul 2000 20:28:44 EST." <200007250028.UAA07840@maynard.mail.mindspring.net> Message-ID: <200007270350.UAA30306@tesla.EECS.Berkeley.EDU> OK, so I can't repeat the crash anymore with the fix I put in in place. However, I don't think your crash was related to my recent fix (in the CVS repository). Can you tell me a little more about your behavior? Are you casting lots of spells, anything "interesting"? In any case, your particular crashes seem to have to do with runes/traps somehow. PeterM > Server: CVS 07/21/00 snapshot > Intel x86 PC, 486DX4-100, 32 Mb RAM, SuSE Linux 6.4 > Client: CVS 07/21/00 snapshot (X11 client) > (same machine) > > I have had my server die twice now at level three on the Dragon Quest. > Both times the server logged a "Trying to remove removed object." > message (details below). > > Following the first failure, I restarted the client and server and > wandered back down into the dungeon. The server did not die this time, > but I was unable to go to level three: > > ---- > xsize 32 Ysize 23 wallstyle cave2 floorstyle stones2 > monsterstyle dragon decorstyle craters exitstyle sstair > final_map /peterm/quests/dragonquest2 > dungeon_level 4 dungeon_depth 12 > orientation 1 origin_x 16 origin_y 9 > > The /random/0000000000000026 is closed. > ---- > > I left the server running and ignored it for a couple of days. This > evening when I tried again, the server crashed again. > > Any suggestions? Anyone else seeing this? > > > Failure #1 > ---------- > --snip-- > Couldn't find archetype rough_2_1_1 > Couldn't find archetype rough_2_1_1 > Couldn't find archetype rough_2_1_1 > > SIGSEGV received. > Emergency saves disabled, no save attempted > Cleaning up... > Saving map /styles/floorstyles/outdoor_lush > --snip-- > Saving map /styles/trapstyles/traps > Trying to remove removed object. > arch trap_blades > name Blades trap > msg > You set off a Blades trap! > endmsg > face blades.111 > animation trap_blades > is_animated 0 > Cha 20 > hp 1 > dam 90 > speed 1.000000 > speed_left 0.900000 > level 1 > type 154 > attacktype 1 > invisible 1 > no_pick 1 > walk_on 1 > end > ---------- > > Failure #2 > ---------- > --snip-- > Saving map /styles/trapstyles/traps > Trying to remove removed object. > arch rune_poison_cloud > name Rune of Poison Cloud > slaying poison cloud > msg > You detonate a Rune of Poison Cloud! > endmsg > face rune_pcloud.111 > animation rune_poison_cloud > is_animated 0 > Cha 20 > hp 1 > speed 1.000000 > level 1 > type 154 > attacktype 6 > invisible 1 > no_pick 1 > walk_on 1 > end > ---------- > > > Frank McKenney, McKenney Associates > Richmond, Virginia / (804) 320-4887 > E-mail: frank_mckenney@mindspring.com > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From cpeirce at enderthethird.com Thu Jul 27 21:51:05 2000 From: cpeirce at enderthethird.com (Conner Peirce) Date: Thu Jan 13 18:03:35 2005 Subject: [CF List] Looping Mailing List... Message-ID: <20000728025105.19738.qmail@pb151.postoffice.net> This looping of the mailing list is starting to get REALLY annoying... is there any (obvious) way to fix it? Oh well...