GCC 2.95.3 works fine, why not support it?

[malakin]

I noticed all I had to do to get showeq working with GCC 2.95.3 was replace the "and" in spelllist.cpp lines 67, 69 and 71 with the traditional &&.

This matters less nowadays that gcc 3x is finally becoming the new standard among distros but it's still a hassle for most people to upgrade so I don't see any reason why GCC 2.95.3 shouldn't be supported?

I appreciate how someone cleaned up my rather ugly looking con color code but I think the older code worked better, cyan gradients are nice, in Sins (where the code originally came from) I can glance at a cyan and know it's level.

One odd thing I noticed is I can't set the even con color to white. My default kde background color is black so white is the logical setting. Putting it to 254 254 254 works fine, just not 255 255 255.

[fee]

Hi Malakin,

Good to see you are still around.



I noticed all I had to do to get showeq working with GCC 2.95.3 was replace the "and" in spelllist.cpp lines 67, 69 and 71 with the traditional &&.

This matters less nowadays that gcc 3x is finally becoming the new standard among distros but it's still a hassle for most people to upgrade so I don't see any reason why GCC 2.95.3 shouldn't be supported?

I'm going to replace the 'and' with && in spelllist on my next update. I like the && convention better. The only reason the gcc requirement came about was to solve a c++ abi issue with libEQ. With the coming gcc 3.1, 3.1.1 and 3.2 and the abi changes they contained it was decided to make the required functions in LibEQ external. So technically the requirement was lifted then.

Other issues have come and gone too. For awhile there existed some ansi conventions not supported by gcc2.95 that were in use in showeq. It appears those have also disappeared.

So for people with old distros, if you can build all your libs and showeq with another compiler, Have fun!



I appreciate how someone cleaned up my rather ugly looking con color code but I think the older code worked better, cyan gradients are nice, in Sins (where the code originally came from) I can glance at a cyan and know it's level.


Not sure I follow you. Cyan shows up on my screen just fine. I do know for a fact there are several level ranges that are just wrong in the code. Perhaps this is what you are running into?



One odd thing I noticed is I can't set the even con color to white. My default kde background color is black so white is the logical setting. Putting it to 254 254 254 works fine, just not 255 255 255.

You are talking about the spawn colors displayed on the map or in the spawnlist? The color on the map is 255,255,255 by default.

Fee

[malakin]

Good to see you are still around. I haven't played in ages but I'm gearing up for the new expansion :)


The only reason the gcc requirement came about was to solve a c++ abi issue with libEQ....
I'm aware of all the reasons 3x support was required but 2.95.3 worked the last time I tried it also which was quite a while ago, although I remember having to edit the source in three places back then. It would be nice if a simple "./configure --enable-old-compiler" worked for 2.95.3, or the compiler check was removed if it's not needed(?).


Not sure I follow you. Cyan shows up on my screen just fine.
Line 1059 player.cpp has commented "// light blue cons, no need to gradient a small range"
So all cyans show up as one color, there is no gradient.


You are talking about the spawn colors displayed on the map or in the spawnlist?
I meant on the spawn list. If you set something to white it appears black so I end up getting black on black.

[Cryonic]

You mean like (see bolded text):



dohpaZ (22/06/02)
------------------
Modifications:
+ version 4.2.12
+ Applied patch # 569708 "bugfix for filter.cpp" by mydor
+ Applied patch # 570621 "Update to saving of player inventory"
+ Applied patch from Sparr (new opcodes, packet structures, races,
+ Added Source Navigator 5.0 project showeq.proj.
+ Changed FlushPackets VPacket setting to default to true.
+ Changed maximum value on the "Walk Path Length" spinbox to be 8192. Please
remember that the walk path option can use a lot of memory.
+ Added the ability to show the walk paths of all NPCs, available from the
"NPC Walk Paths" option of the "Show" sub-menu of the maps right-click context menu.
+ Fixed a bug where if there wasn't a template filter file an empty one with a section named "[Spawn]" would be created instead of using the proper filter section name.
+ Added "Save Selected Spans Path" and "Save NPC Spawn Paths" items to the "File" menu. They will respectively save the currently selected spawns or all spawns walk paths to a file <MAPDIR>/<Short Zone Name>_mobpath.map.
+ Fixed a file format handling bug in drawmap.cgi. No longer pretend to use extra fields on the first line of the map file.
+ Added book information to player inventory.
+ Optimized slot_to_name() function. Fixed bug generating names for slots in containers in the general and bank slots. Moved it in with the other in utility functions in util.cpp.
+ "No Bank" should only effect the display of bank items, made it so the bank info gets dumped irregardless of its setting.
+ Workaround for Qt 3.0.[1-4] bug involving slots that take an int argument with the string "int" in the name being unable to recieve events from menus (just renamed them all). Qt 3.0.x now officially supported (and is about as supported as it will be until ShowEQ 5, whenever that is). This also makes it so that RedHat 7.3 (and possibly Mandrake 8.2) users can compile out of the box using "./configure --enable-old-compiler"

[malakin]

You mean like (see bolded text):
My point is it doesn't work, not with 2.95.3 at least which is the latest pre 3x gcc release.

[fee]

actually 2.95.4 was the latest in the 2.95.x series. But unfortunatly redhat decided to force 2.96 on the world. Blame them.

Submit a patch to fix these problems and we'll get it added.


Fee

[malakin]

actually 2.95.4 was the latest in the 2.95.x series. But unfortunatly redhat decided to force 2.96 on the world. Blame them.
Not that this even matters but... 2.95.3 is definitely the latest 2.9x gcc release.
Neither 2.96 or 2.95.4 are gcc releases.
http://gcc.gnu.org/releases.html

I'll post a patch for the the compiler detection, I brought it up to make sure there wasn't other issues I wasn't aware of. Maybe I'll post a patch for cyan gradients also :)

[adenine!]

Not that this even matters but... 2.95.3 is definitely the latest 2.9x gcc release.
Neither 2.96 or 2.95.4 are gcc releases.

Don't know about 2.95.4, but 2.96 was developed by RedHat, included in some of the distributions (6? 7?), and notoriously crappy.