Thanks for your thorough reply.
On 10.06.23 14:02, CSS Dixieland wrote:
Yes, Mister Papanagnou, Your information about integer arithmetic calculations versus floating point calculations is correct, but it is
to be expected that it had to be so, considering the reality of the
times. There were a few experimental dungeon games for computer in
the 1970s, though the game that became seminal (to the extent of even
giving its own name to the whole genre, often known as 'Rogue-like'
games) was the game called Rogue, released in 1980. Successor dungeon
games were more or less inspired on Rogue, but not directly derived
from it in terms of source code, because the code of Rogue was
proprietary and could not be legally copied.
I think what you wrote is partly not quite accurate or even wrong.
I'm too lazy to look up every detail again; what I say is (partly)
from memory (so take that with a grain of salt if you like)...
WRT rogue; developed at Berkeley and distributed with BSD Unix, it
spread extremely fast. (A _commercial_ DOS version was later ported
and sold, separately. You were probably referring to that version.)
Many years ago I collected some information that you find here:
http://rogue.gridbug.de/
It's unlikely that the reason for not using FP was lack of processor
features. After all we linked FP libraries to the programs where we
wanted them. My personal _thought_/_opinion_ at that time was that
since the game is widely discrete (in time and space models) there's
no need to use FP, thus saving space - which was precious and rarer
at that time! In the source code I could see at some places strange
routines handling with integers in a complex way to implement the
counterpart of a [simple] FP function (ISTR, e.g., an integer sqrt()
function).
[snip processor history]
I do not think necessary to give the list of the most important microprocessors that were released in the 1990s, because by the 1980s
dungeon games ('Rogue-likes') were already firmly established.
As You mention, the first implementations of such games used integer arithmetic calculations. Later, one implementation after another
began using floating point, as it became available in the hardware.
It was of course possible to do floating point calculations by
cumbersome software methods, and it was in fact done so for critical applications, but to my knowledge, it was not done for games. It is enormously easier to do floating point calculations in the hardware,
If you have a FP library it's just function calls, it's not difficult.
You don't address the FP hardware directly from your source code. The
compiler creates code to call functions or to use FP opcodes supported
by the CPU or later by the (nowadays typical) FP co-processors. ISTR
that I could omit linking some "lib???.a" if I had not used the 'float'
data type in a C program. That way we could reduce the executable size.
once such hardware became available, therefore game programmers
introduced floating point only when hardware engineers had introduced floating point. Which is, I presume, perfectly understandable.
I used always (also around 1980) FP in programming where appropriate.
(In a fully discrete game it would not be necessary, but if it solves
an implementation task it's easy to use. In some places they _should_
have used FP but didn't; e.g. the first arcade tennis games for TV
could be held in a ping-pong stable state without doing anything; a
negative and certainly undesired effect of rough quantification.)
The procedure that You have delineated is in theory feasible,
(Not only in theory.)
but I am not going to implement it.
(Erm... - no one asked you to do so. - I also wasn't even aware that
you are a programmer/maintainer of some variant; if that's what you
imply here. - I was merely discussing features.)
[...]
You are certainly free to disagree with me, Sir, and very free to do
YOUR OWN IMPLEMENTATION.
(Wow! - Why are you shouting? - I find it always amazing when lacking
arguments result in strawman arguments and non-topical red herrings.
We should probably stop our discussion since you appear to have got
offended by my disagreement to one of your statements? - It wasn't
intended, be assured.)
Most dungeon games are open source, meaning that You can obtain and
modify the source. Using a different programming language if You
prefer, taking the source just as a procedural guide for Your own implementation. [...]
In reply to a maintainer of a variant - who showed the same counter
reflex - I already said that I'm not inclined to publish yet another
variant; I think we already have more than necessary. And I have other priorities than adding one more variant to that huge roguelike zoo.
My own preference would be if some concepts/variants would converge
to one better variant and reduce the size of the zoo. But maintainers
often seem to be reluctant to give up their "baby"; I understand that.
So we see variants that differ in number and layout of levels, names
of artifacts, number of items and monsters, etc. *shrug*. </rant>
For me, Nethack and its derivatives are well as they are. I do not
deny that Your idea would improve the game, for it surely would
improve it, but I am of the view that the result is not worth the
effort of programming with so much detail, and I am widely considered
a perfectionist. I have some reason to suppose that most programmers
will probably agree with my position. There are many thousands of
lines in each of the various source codes, and just a tiny error may
have fatal consequences.
Reading this; you doesn't seem to be a software engineer, are you?
What you write makes no sense in the context that we were discussing;
adding, merging, refactoring, and testing code, is a regular business
of software engineers. Variant developers do that all the time. This
is no exception for the (quite primitive) change we have been talking
about in this thread.
[ snipped some final fluffy digression about bugs/testing ]
Janis
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)