New answers tagged

2

My experience with python in amiga OS 3.1 was it needed a lot of stack. Perhaps this also works in os3.9? Try increase the stack which back then allowed max 25000 (using the command 'stack 25000'). As to the "get additional python libs", I do not see how you can get around compiling. Any pure-python extension that is 'old enough' has a chance to ...


2

I think your question must be put a bit differently for a first step towards an answer, like "was it common to use localized Unix applications from 70ies to nineties?" - In my opinion, the answer to that is already "no" (although improving towards the end of the period). The simple reason for that that most applications were specialized, ...


1

Is it historically correct to say that Unix programmers, liking to pretend that character strings and byte arrays were the same thing anyway, never really adopted wchar_t and in practice wide use was never made of wchar_t support? Yes and no. For one, Unicode did make quite an inroad for Unix in the 90s - and more often than not using a 16 bit type. But of ...


16

Probably the easiest way to discover whether a cartridge was started on a GameBoy Advance is to look at the initial register state. According to nitro2k01 at gbdev.gg8.se: cgb_agb_boot.bin - Gameboy Color boot ROM used in GBA's GBC mode This revision of the GBC boot ROM was used in GBA's GBC compatibility mode and has the following changes from the ...


1

In the original Doom, you can't look up and down. The display renderer draws the walls as strips of textured vertical lines and doesn't have the capability to tilt wall textures backward and forward. This keeps it fast. Some later Doom-engine based games did allow a small amount of looking up and down (Heretic IIRC) and then you can see why - since the ...


4

DOOM comes from an era when stability of the game's rules/mechanics actually mattered. Folks were generally unhappy when an upgrade to the game broke their existing demo recordings, and for the most part, the updates to the game engine avoided doing that. Note that this also matters for things like trying to score achievements, where changes to the rules, ...


0

This seems to be just neglectful programming. The other answers mention Doom (and Doom II) being based on a ‘2½-dimensional’ engine (later retroactively named id Tech 1), meaning the engine internally keeps floor and ceiling heights bolted on to what would otherwise be a two-dimensional map. While this is true, and it does limit the game environment in ...


0

Think in the other direction: Monsters chase players, if they are allowed to be above a player, they are in a spot where they cannot be seen and cannot be shot at.


43

Doom maps and locations on the maps were essentially 2D. This makes a lot of stuff much cheaper to calculate that a general 3D solution but has some limitations: objects can't stack, you can't jump over them, you can shoot them by aiming over/under them and paths can't pass over/under other paths. But 99% of the time you don't notice any of this :o)


33

Allowing two objects to occupy the same position in XY space but different elevations would create the possibility that one object might collide with another from above or below. While this might not be a problem when dealing with projectile weapons that would naturally be destroyed in the collision, it would pose some complications if e.g. a player could ...


20

If f is a floating-point number and n is a non-negative integer, then the expression INT(f*10^n + 0.5)/10^n rounds f to n digits of precision after the decimal point, rounding up or down depending on what's closest. For comparison, the expression INT(f*10^n)/10^n rounds f downward. The Python equivalent is round(f, n) so you can translate the code from ...


21

They likely translated some formula literally where the 10 was actually some variable, but in their use case, it was fixed at 10. For your purposes you can safely use 100.


-1

Symbol table space was the most likely culprit. Integers and floating point values were known sizes. Strings were problematic. The interpreter (or P-code) had to keep track of all the variables and their contents. floating and integer types were easy to store, as they had a known size. strings were trickier and required additional information to store, such ...


2

Firstly there is more than one way to assign a value to a variable. Eg input x, y Print x+y If the input is 4 and 2, should the interpreter return 6 or "42"? You need to be able to tell apart strings and numbers. Secondly limited memory space was a major consideration back then. Strings usually reserved 256 bytes, whereas numbers required much ...


5

Section 7.1 of the ANSI X3.60-1978/EMCA-55 Minimal BASIC Standard specifies that string variable names end in the "$" character. That particular string variable naming specification allowed the Standard to be backwards compatible with the 1968 implementation of Dartmouth BASIC (and with DEC BASIC, et.al.). So support for that type of string ...


3

Any answer to this question is going to be somewhat a matter of opinion, since there certainly are languages that are designed with dynamic typing, and BASIC could have been done that way. Unless someone comes up with a memoir or historical article explaining some of these design decisions, we won't really have a conclusive answer. I disagree with the ...


1

Just to add to the other answers - a somewhat odd solution, but doable for simple (but longish) "drawing" programs such as this, is to use Wozniak's old "Integer BASIC" (aka "Apple BASIC") instead of the more common (Microsoft-BASIC derived) "Applesoft BASIC". You do that by saying "INT" at the prompt after ...


24

To add to the "because it's BASIC" answers: BASIC came from the Dartmouth Timesharing System (DTSS) in the 1960s. Other implementations need to follow basic BASIC standards. In 1964, the variables A and A() -- i.e., scalar and array -- were considered to be different. BASIC, Oct 1964, page 36. There were no string variables. By 1968, string ...


7

Akin to Raffzahn's answer, yes, because it's BASIC. That said, later BASICs had DEFINT, DEFSTR, and such to set the types of variables upfront, so that you no longer had to use suffixes. Similar to the IMPLICIT statement in FORTRAN.


39

TL;DR: Most straight answer: Because it's BASIC A trailing '$'-sign is the syntax BASIC defined when adding strings. Also, the suffix is not only a type marker, but part of the name. In BASIC A and A$ are two different variables. This is not a bug but a feature. The type is needed to distinguish them. The BASIC language is defined to work that way. Changing ...


Top 50 recent answers are included