small cosmetic improvements

NOTICE: This forum is archived as read only.
Please use the Github Discussions at https://github.com/exult/exult/discussions
Forum rules
NOTICE: This forum is archived as read only.
Please use the Github Discussions at https://github.com/exult/exult/discussions
Locked
dag

small cosmetic improvements

Post by dag »

talking about being pedantic (see pocketwatch thread)...

1. in the character stats screen, the "hits/mana" section is one pixel to low.
okay, this is *really* pedantic. ;-)

2. the spellbooks' letters are perfectly glowing now -- but there's not enough
space between them, so they quite hard to read now! i just checked the
original; they are perfectly readable there...

am i the only one who has encountered those small glitches or can someone
verify this...?

bg, using 1.1 branch, latest snapshot
(i've had problem #1 with other snapshots, too)
win98se
Dominus
Site Admin
Posts: 5656
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Dominus »

did you try this without scalers enabled?
--
Read the documentation and the FAQ! There is no excuse for not reading them! RTFM
Read the Rules!
We do not support Piracy/Abandonware/Warez!
dag

Re: small cosmetic improvements

Post by dag »

yes, but enabling the scalers doesn't seem to make a difference.

already tried:
- opengl, 1x
- point, 1x
- point, 2x
- interlaced, 2x
- bilinear, 2x
- bilinearplus, 2x
- 2x sai, 2x

all full screen and windowed; resolution 512x384 and 320x200
dag

Re: small cosmetic improvements

Post by dag »

by the way... is it "technically possible" and "not too hard to implement"
to use bilinear filtering with the opengl scaler (maybe with the use
of anisotrophic filtering)?
i guess, since it is done in hardware, there may be just a minor speed
decrease, but a huge increase of visual quality...
dag

Re: small cosmetic improvements

Post by dag »

i just tried it [see 1st post] with an older display driver -- no difference.
Trevor_Clim

Re: small cosmetic improvements

Post by Trevor_Clim »

by the way, which scaler do you prefer and why?
dag

Re: small cosmetic improvements

Post by dag »

those scalers are a quite cool, but i prefer the point/opengl-scalers,
because they are fast (even at heigh resolutions) and give me that
i-am-playing-the-original feeling.
i am not absolutely sure, but i think opengl is a bit faster than point.
(i've experimented a *lot*)
SB-X
Posts: 980
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by SB-X »

Scalers disabled gives the i-am-playing-the-original feeling...
Darke
Site Admin
Posts: 173
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Darke »

Rubbish. Spending an hour getting the game to work, then spending the
next day/week/month fiddling with smartdrive/hymen.sys, editors to pare
your autoexec.bat and config.sys files down to absolutely nothing so you
can get mouse AND sound AND fast save games... _that_ gives you the
I Am Playing The Original(tm) feeling. *grin*
Darke
Site Admin
Posts: 173
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Darke »

Mental Note: Only after getting pretty much no sleep the previous night
can one mistake a 'himem' for a 'hymen' and visa versa. Don't do this. The
results can be... messy.
Telemachos

Re: small cosmetic improvements

Post by Telemachos »

lol... Darke you bad boy ;) I bet you like to spend a month fiddling with hymen ?!? ;) One of the nicer typos I've seen lately ;)

- Tele
dag

Re: small cosmetic improvements

Post by dag »

i remember i spent months with setting up my os so that bg/si worked
with all options and with a laaarge diskcache. i even created a mixture
of ms-/dr-/novell-dos in order to free as many bytes as possible....

now... has anybody else noticed the little pixel glitches mentioned above..?
ascendence
Posts: 14
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by ascendence »

why even worry about cosmetics right now? to answer, no i havent noticed either 'glitch'.
-kel, deity of sarcasm
dag

Re: small cosmetic improvements

Post by dag »

sorry, perhaps my bad english may lead to some confusion.

i really don't want to be pedantic, but at least the second part of my
post may be worth considering, because being able to read the spell
circle and the number of spells with the available amount of reagents
could be quite useful....

so all i would like to know is if anyone else is facing the same issue...
i just don't want to go to the bug-report-section without making sure
that i am not the only one getting those little "pixel errors".
Darke
Site Admin
Posts: 173
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Darke »

What language/which version of BG/SI are you using? We've had a few
odd problems with different languages/versions to the one the devs tend
to use (english/BG+FOV+SI+SS).
dag

Re: small cosmetic improvements

Post by dag »

i use the american version that came with the 'complete ultima cd'
included in the ultima ascension package.
that should be a quite actual version.
Dirty Hairy

Re: small cosmetic improvements

Post by Dirty Hairy »

By the way (sligthly off-topic), when talking of scalers: can I get the opengl-scaler to work with the binary snapshot, or do I have to compile my own?
dag

Re: small cosmetic improvements

Post by dag »

i guess you talk about running exult on linux. when you run exult with
windows, there should be no problem with the opengl scaler.
Dirty Hairy

Re: small cosmetic improvements

Post by Dirty Hairy »

I'm using the windows-port. There is no problem in selecting the scaler, but it doesn't activate properly - it only tells me opengl-support is not activated (in stdout) - I suppose opengl-support isn't compiled into the binary.
By the way, I tried to compile the snapshot using mingw (with opengl activated ), but make stops coplaining about the first .o - file and "error 1". According to the compilation output, it seems that only the first object file in the list is given as parameter for gcc. I tried hacking aroung a bit in the makefiles, but that didn't help much - small wonder as I only have basic knowledge about c and make :-).
Has anybody encountered that problem or got a solution for me?
dag

Re: small cosmetic improvements

Post by dag »

???

hard to say, since i only use the downloadable binaries...
works fine for me there...
Colourless
Site Admin
Posts: 731
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Colourless »

It is strongly recommended that you DO NOT use the OpenGL mode.

It sort of works ok, but it's no where near feature complete. Palette rotations and changes will not work at all in OpenGL mode. That means you will not get day/night cycles, caves will not be dark, and there are a number of other problems too.

-Colourless Dragon
Zosite
Posts: 101
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Zosite »

You´re right about your "cosmetic problems" Dag. I´m going to reopen the bug 640393:"Spellbook numbers don´t glow". Although the first complain could be some pedantic the second problem is actually annoying...

And so far! The page-turning doesn´t work as in the original U7 since it doesn´t seem "realistic"; look which spells should be seen while pages are turning...
And the red band used to mark spells must be also used to take you to the page where it´s located when clicking on it; In Exult you can´t see the band on the top if you´re not on its page.
Hmm... but I´ll submit a new bug report about the band...

BTW: Thanks for the OpenGL warning, Colourless; Avoiding tragedies is always a good way to prevent unnecessary bug complains. [;-))
-Zósite K.S. from Moonlightshadow-
Darke
Site Admin
Posts: 173
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Darke »

The problem is the numbers _do_ glow, so you're better off making
another bug report. *grin* Check yesterday's #exult logs for the problems
I found/confirmed with the spell book's lettering.

As to the page turning, I really don't remember a difference between that
and the original, not that I've seen the original in... umm... 6 or more
years. *grin*
Meat Shield

Re: small cosmetic improvements

Post by Meat Shield »

No dark caves. Good, then I can see!! *feature, not a bug*
dag

Re: small cosmetic improvements

Post by dag »

strange, i haven't noticed any major difference between point and
opengl scalers on my system... even the caves are dark and the
palette rotations seem to work -- but probably i'm just some kind of
lucky...
Dominus
Site Admin
Posts: 5656
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Dominus »

dag: as I understood from your posts you are using the snapshot from our download page. Even though OpenGL is an option there it is not working as it wasn't compiled with OpenGL options. So of course you are not seeing any difference as it is not working.
Reminder: Scalers only work if it is set to 2 -> 1 is no scaler.
(for the nitpicky, some scaler suport also 3, 4...)
--
Read the documentation and the FAQ! There is no excuse for not reading them! RTFM
Read the Rules!
We do not support Piracy/Abandonware/Warez!
dag

Re: small cosmetic improvements

Post by dag »

dominus: so _this_ is the reason why i could not see a big difference
between point and opengl... :-)

aargh!! i spent hours with experimenting with my video-driver-settings
like bit-depth, anisotropic filtering, antialiasing and much more...! only
to come to the conlusion that it is "point"-less...

full opengl implementation may be quite complex, so i expect that it will
not be done in the near future. however, it would be a very nice feature,
because one could use the bilinear filter provided by the video-hardware.
Dirty Hairy

Re: small cosmetic improvements

Post by Dirty Hairy »

Thanks for the warning, colourless; you have prevented countless hours of fruitless compilation attempts. Still: can anybody give me a clue about the make problem...?
daq: I think it possible that even with full opengl-implementation, the result would't look as good as the other scalers. There is a opengl-implementation of scummvm (if you know it :-) ), and it looks quite blurry, since hardware filtering was created to blur textures...
Zosite
Posts: 101
Joined: Thu May 14, 2020 1:34 pm

Well said, Darke...

Post by Zosite »

>Author: Darke

>The problem is the numbers _do_ glow, so you're better off making
>another bug report. *grin* Check yesterday's #exult logs for the >problems I found/confirmed with the spell book's lettering.

Ok, Darke; I´ll submit a new bug report and close again the old one. I suppose it´s annoying to see the same bug report again and again even if it´s related to new issues... [:-))

Page turning? It seems you should take a look again to the original U7 after 6 years... On the other hand you may have an amazing memory due to your logs in #Exult... good ones!
-Zósite K.S. from Moonlightshadow-
TruchiDragon

Re: small cosmetic improvements

Post by TruchiDragon »

why so much interest on Blilinear Filtering dag?
AFAIK, Bilinear Filtering is used on 3D surfaces so you see a smoother surface at the distance (like a blur).

Bilinear filtering uses ONE line to divide the 'normal' rendering from the 'smoothed' rendering, and Trilinear Filtering, uses TWO lines, hence having more detail in the softening process (so it looks more realistic)

now i dont have a clue of why would this be nice on a 2D/'top view' game ;)

Truchi
dag

Re: small cosmetic improvements

Post by dag »

truchi: i was just thinking of how to possibly speed up the scalers in high
resolutions on slower pcs. so hardware filtering came to my mind as it does
not need much cpu power at all.
winuae [an amiga emulator for windows], for example, does quite a
good job here. the result is not blury at all, it is just a bit... softened.
Colourless
Site Admin
Posts: 731
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Colourless »

TruchiDragon, you really have no idea about what Bilinear and Trilinear are and how they work. It's got nothing at all to do with lines.
dag

opengl support

Post by dag »

now, i am just wondering if the exult team is considering to implement
opengl support for graphics output or not.
since exult is being developed with linux [i am a m$windows user:-(] i don't
know if it is easy to cross-develop this with several operating systems.
it may be not...
does anyone know anything about this?
drcode
Site Admin
Posts: 2267
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by drcode »

There is some very dodgy OpenGL support in Exult, AFIK only tested under Linux. My experience with it is that it does speed up the game quite a bit. But it doesn't look nearly as good as the scalers that Derek did, has some annoying artifacts (like lines between the chunks), and it sometimes crashes my machine (which otherwise NEVER happens to me in Linux).

I may work on it more someday, but I'm not sure if it's worth the effort.
nadir
Site Admin
Posts: 407
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by nadir »

DrCode, I think that Colourless has done some fixes on the OpenGL code, so it's not as bad as you describe.
dag

Re: small cosmetic improvements

Post by dag »

cool... so maybe opengl really _could_ be a further improvement to
the engine!
i just like the idea of not letting sleep all this hardware stuff that almost
everyone has plugged to his/her cpu. ;-)
drcode
Site Admin
Posts: 2267
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by drcode »

I'd certainly welcome any help anyone wants to give on this. Colourless did fix some of my goofs, but I'm still seeing fine lines between the chunks. Maybe someone who's worked a lot with OpenGL would know right away what's wrong.

One thing that's been suggested is that we could perhaps start replacing some of the 2D graphics with 3D models.
Grimlock Dragon
Posts: 56
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Grimlock Dragon »

Hmmm.... I suppose that the 3D models would be highly simplistic (seeing as there are only a few body types), and then the old 2D character graphics could be overlayed as skins on top of it? Of course then there's every other object in the world that could be 3D rendered. Hmm... are there any programs that could automatically do that with the shape file graphics? Perhaps the most that could be done with the original graphics as far as 3D is concerned is for them to appear like raised figures on the screen with shadows, and other shading.

Wasn't there someone (a female, I believe) that posted a 3D rendering using U7's grass background, and adding a Cacodemon from Doom?
Colourless
Site Admin
Posts: 731
Joined: Thu May 14, 2020 1:34 pm

Re: small cosmetic improvements

Post by Colourless »

DrCode, I know what is wrong with it, just finding a reasonable fix isn't the simplest. However, after thinking about it, i have an idea that might work. I'll try it out later. It might even work in Pentagram too (which has the same problem)
Locked