Enterprise Forever
:UK => Programming => Topic started by: jonesypeter on 2020.October.02. 12:34:33
-
Hello,
I'm coming from a ZX Spectrum background, and wondered if anyone could give me an example in BASIC of using the 'Graphics Attribute' mode? I looked in the manual, but can't see any examples.
Also, is there the equivalent of the Spectrum ATTR (X,Y) command which is useful when writing games in BASIC to find the attributes of a cell at a particular position.
Many thanks
Peter
-
A game that uses attribute mode is Gombócfaló by Attus. You can download it here, in .rar format. (http://www.ep128.hu/Ep_Games/Prg/Basic_Program_Pack.rar) There are a lot of basic programs here, you have to look at GOMBOCF.BAS in the rar pack.
I don't know the Spectrum's ATTR() command. You may look for the command LOOK #chan:AT X,Y. However it gives you the colour of a pixel, not the code of a character. You can handle the attribute screen both as a text window and as a graphical window and the two types of windows can be referret to in a different way. (So, X,Y will be very different if you PRINT AT X,Y and if you draw using PLOT X,Y.)
-
Thank you szipucsu
How do I load .bas files into ep128emu please?
Thanks
-
On the menu Options/Set working directory, select the directory where you have the files.
On the menu File/Configuration/Load from ASCII file, select one of the configurations(on the EP12emu/Config directory) that include "FileIO" at the end of the name. The emulated EP will reset itself.
Then on Basic, you must execute LOAD "", without file name, to force the emulator to show a file manager from which you can select your file. All programs will use the directory as the default storage unit.
-
Thank you, that worked.
I looked at the look command and that is not quite what I'm looking for. What I'm after is being able to find what character code is at an x,y print position.
Something like this:
So start with this:
PRINT AT 11,16;"*"
Then
SCREEN$ is the reverse function to PRINT AT, and will tell you (within limits) what character is at a particular position on the screen. It uses line and column numbers in the same way as PRINT AT, but enclosed in brackets: for instance PRINT SCREEN$ (11,16) would print "*", which you could assign to a variable.
It allows for basic collision detection is BASIC.
Thanks
-
The right way is the one that Szipucsu has pointed, but the graphics screens, and Attribute mode is graphics, return the palette colour on the pixel. The text screens return the character on the text coordinates with the same LOOK command.
[attachimg=1] (http://enterprise.iko.hu/technical/ET11-11_EXOS_21_Video_Driver_Specification.pdf)
Still there is an option: create a 2 dimensions string matrix with the same measures, and print on it the same characters that you have put on the real screen. To clear the matrix very fast you only need to close it and re-define it again.
-
What I'm after is being able to find what character code is at an x,y print position.
...
PRINT AT 11,16;"*"
...
PRINT SCREEN$ (11,16) would print "*", which you could assign to a variable.
Unfortunately attribute mode is rather a graphical mode than a text mode. So in attribute mode there is not a simple solution for this. As GFlorez wrote you should ask for the pixel colour of the character's position. (However it seems difficult as character X,Y position is stored differently from the pixel X,Y position. The game Gombócfaló linked above solves this in some way but I don't know how.) I would rather create a matrix that Gflorez wrote so if you print something you should fill the parallel content of the matrix, e.g. PRINT AT 3,5:"B":LET SC$(3,5)="B".
If you do not use attribute mode but text mode you can solve it easily:
PRINT #chan:AT 3,5:;
GET #chan:A$
So you can get the character.
Other suggestion: you can use 4-colour character mode instead of attribute mode and you can use the easier method. However you have only 3+1 colours. I still prefer 4-colour character mode to attribute mode because I can have character animation. In an attribute screen characters are printed on the screen but they are no more considered characters, they are only some group of pixels as any other graphic item. They cannot be overwritten by space characters. You have to switch to the background colour, print a character full of pixel so you can remove your character from the attribute screen. It is somewhat slow but you can use Zzzip compiler for higher speed.
-
Well, in general, you shouldn't regard screen memory as your data store - I'm sure your program knows the position of things in other places (like "PlayerX, playerY",...) as well. If you are doing collision detection based on these positions, you might be better off for all possible modes.
-
There is another tricky way... Knowing the LPT address, the text buffer address can be found on one of the lines, and with the use of SPEEK and a simple formule you can know the character on the text coordinate.
-
They cannot be overwritten by space characters.
Actually, it seems that in ATTRIBUTE mode, you can overwrite by printing with space characters. Although that doesn't work in the other graphics modes, only in attribute mode.
-
in ATTRIBUTE mode, you can overwrite by printing with space characters
Wow, you are right. I have just tried it.
Knowing the LPT address, the text buffer address can be found on one of the lines, and with the use of SPEEK and a simple formule you can know the character on the text coordinate.
Yes, but it does not work with the attribute mode, only with the pure text modes. (I think.) It is an alternative for GET #chan:A$ and is faster.
-
Yes, you are right... the buffer zones of the attribute mode are pixel and attr., not text.
Off topic: The Amstrad CPC is a totally graphic computer, it doesn't have a text mode nor a buffer, but can emulate it. There is a Rom function that returns the value of a character given certain coordinates. A workaround is used: the rows of bytes that are found on the coordinates(on text boundaries) are compared with all the ones on the character set until a match is found.
-
The Amstrad CPC
There is a Rom function that returns the value of a character given certain coordinates. A workaround is used: the rows of bytes that are found on the coordinates(on text boundaries) are compared with all the ones on the character set until a match is found.
It is interesting, I didn't know that! This is why editing seems so complicated for me: I cannot simply go back to the previous line to edit it and press enter again, I think.
If so: what happens if you redefine the character set? The rows of bytes cannot be compared with the rows of the character set. You could define the same shape to more than one character, it can mislead the machine. Or, maybe, there is no option to redefine characters and "problem solved".
-
There is a Rom function that returns the value of a character given certain coordinates. A workaround is used: the rows of bytes that are found on the coordinates(on text boundaries) are compared with all the ones on the character set until a match is found.
Which is of course not exactly blazingly fast.... That ROM function needs to scan through the whole character set worst case.
-
Off topic: The Amstrad CPC is a totally graphic computer, it doesn't have a text mode nor a buffer, but can emulate it. There is a Rom function that returns the value of a character given certain coordinates. A workaround is used: the rows of bytes that are found on the coordinates(on text boundaries) are compared with all the ones on the character set until a match is found.
I think this is probably what the Spectrum does as well with the SCREEN$ command. The Spectrum display is not a text buffer either. It's an attribute-based graphical display.
-
If such option were implemented on an EP, it would be no problem, as the character set is also modified.
-
Which is of course not exactly blazingly fast.... That ROM function needs to scan through the whole character set worst case.
Not so slow, if a match is found on the first byte of the character, then its next line will be compared. If not, the next character. This task is fast on Machine code.
I think this is probably what the Spectrum does as well with the SCREEN$ command. The Spectrum display is not a text buffer either. It's an attribute-based graphical display.
I have suffered editing Spectrum basic lines a lot..... It was my first computer. Imagine the release I felt when I started to do(editing) it on the EP.... (The Spectrum is)Good for some things only.