So I'm knee deep in concept design for my new door game. Since I"m doing it in Pascal, inspired by LORD, I'd like to know what tools you all use when designing ANSI screens.
Side note, I'm assuming most people use 80 columns. I'm considering a 40 column mode for C64 players (it would be tight to play a modern door
game with one). So, with that in mind, I'm wanting to design ANSI
screens for the game.
As someone who started bbsing and being a sysop on a c64, that is an awesome idea (i'm working on bringing my old c64 bbs back online). You will want to draw your screens in Petscii then and not ansi and most c64 bbses only support petscii. Petmate (https://nurpax.github.io/petmate/) is a great cross platform opensource editor that you can also run under linux.
Which leads me to a question... if someone with a non C64 machine calls a C64 BBS, does their terminal program also need to support petscii, or
will it render as it does on the server side?
So I'm knee deep in concept design for my new door game. Since I"m doing it in Pascal, inspired by LORD, I'd like to know what tools you all use when designing ANSI screens.
Side note, I'm assuming most people use 80 columns. I'm considering a 40 column mode for C64 players (it would be tight to play a modern door
game with one).
I personally use Moebius which is open source and cross platform (http://www.andyh.org/moebius/) there are others that you can run in Linux, but Moebius is regularly updated and offers some great tools to help you along with drawing stuff.
As someone who started bbsing and being a sysop on a c64, that is an awesome idea (i'm working on bringing my old c64 bbs back online). You will want to draw your screens in Petscii then and not ansi and most c64 bbses only support petscii. Petmate (https://nurpax.github.io/petmate/) is a great cros platform opensource editor that you can also run under linux.
Yes, your client needs to support it. SyncTerm does in fact support c64/c128/amiga fonts and graphics. You also need to manually set them for each entry as it won't convert them on the fly.
I wasn't considering writing the game to run on a C64 because I would consume more RAM than it would have. I was thinking of the C64 as a
client system visiting a board. Or, do C64's have a limit of only being able to visit C64 boards? If that's the case I'm screwed.
64s can call any system, whether they can decipher what's happening is a whole other story. Some of the newer versions of cgterm can do some ansi but for the most part they need to call a system that supports 40 col and either ascii or petscii.
I'm using a 64bit system to learn pascal. I'm hoping there are compile farms I can use for 16 and 32 bit systems so I can provide versions for sysops running boards on retro systems. Is that something I should
concern myself with?
If you're open sourcing it then no, one of us crazy old bastards will
get it compiling for the ancient technologies. Seriously though, 32-bit isn't an issue, just a flag. Doing the 16 (or 32 via extender) thing is probably best left until afterwards. Again if you are open sourcing it then I'll probably take a whack at keeping it build for DOS. I'm kinda a bizarre masochist in that sense.
If you're open sourcing it then no, one of us crazy old bastards will get it compiling for the ancient technologies. Seriously though, 32-bit isn't an issue, just a flag. Doing the 16 (or 32 via extender) thing is probably best left until afterwards. Again if you are open sourcing it then I'll probably take a whack at keeping it build for DOS. I'm kinda a bizarre masochist in that sense.
Yes, yes you are. I want a CoCo build as well.
CoCo as in Color Computer?
I wasn't considering writing the game to run on a C64 because I would consume more RAM than it would have. I was thinking of the C64 as a client system visiting a board. Or, do C64's have a limit of only being able to visit C64 boards? If that's the case I'm screwed.
64s can call any system, whether they can decipher what's happening is a whole other story. Some of the newer versions of cgterm can do some ansi but for the most part they need to call a system that supports 40 col and either ascii or petscii.
|15frank |08// |15netsurge
|07disksh0p|08!|07bbs |08% |07bbs.diskshop.ca |08% |07mystic goodness |11SciNet |03ftn hq |08% |07https://scinet-ftn.org
--- Mystic BBS v1.12 A45 2020/02/18 (Linux/64)
* Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (77:1/100)
Yes, yes you are. I want a CoCo build as well.
Speaking of columns, I use digitaldistortion bbs as my daily board and I connect at 80 columns and 54 rows. Is this standard?
Most systems are designed for 80x25 but as long as it works for you there is no issue. You will find it more difficult to work with smaller or larger columns that rows.
I only ask so I don't screw up my ANSI screen designs.
For menus and such I would keep them at 24 or 25 rows, this way they don't scroll past people's screens who are using a terminal client at it's default settings.
As for images, if you keep them at 80 wide you will be good. You can make them as long as you want. I have a few on my bbs that run at least 70 or 80 rows.
Sometimes a massive image appears when loading LORD. Probably 200 rows deep. Have you seen it? Or am I one of the only people who plays LORD still? Daniel Traechin
Sometimes a massive image appears when loading LORD. Probably 200 rows deep. Have you seen it? Or am I one of the only people who plays LORD
Sometimes a massive image appears when loading LORD. Probably 200 rows deep.
Have you seen it? Or am I one of the only people who plays LORD still?
A lot of people used to call those "scrollers" because they're longer than t terminal window and force it to scroll upwards. It's a cool effect for showing large pieces of art, but something you should probably avoid the res of the time. :)
A scrolling graphic here and there is fine and I wouldn't worry about row-co in that context. Of course, we're not on dial-up anymore, so the graphic fli by in a hurry and mostly goes unappreciated.
More importantly, you shouldn't push important information out of the top of the terminal before the user gets a chance to read it. Keep your menus, etc. sized so that they'll fit the lowest common denominator, or have small/large variants.
Depending on the type of program, I either write it to scale to the size of user's terminal, or I size it for 80x24 and then centre it in the available space.
If having a bigger terminal window lent an advantage in a game, for example (eg. you could see more of a map than other players, or some text wasn't truncated, etc.) then I would probably clamp all users to 80x24.
Speaking of columns, I use digitaldistortion bbs as my daily board and I connect at 80 columns and 54 rows. Is this standard?
The 80 columns is "standard", the 54 rows is not. What terminal program are
| Sysop: | altere |
|---|---|
| Location: | Houston, TX |
| Users: | 69 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 09:09:33 |
| Calls: | 1,062 |
| Calls today: | 2 |
| Files: | 8,069 |
| Messages: | 298,944 |