On Wed, Sep 18, 2013 at 03:01:26AM +0200, Adam D. Ruppe wrote:
> On Tuesday, 17 September 2013 at 17:01:55 UTC, H. S. Teoh wrote:
> >Actually, that gives me an idea. What if, instead of defaulting to character data, the terminal input stream defaults to control structures?
> 
> hehe those who don't understand Windows are doomed to reinvent it :)
> :) :)

lol... though it makes me think of the latest C++ proposals as "those who don't understand D are doomed to reinvent it, poorly". :-P


> >the length) per message, which should minimize the overhead of defaulting to control mode instead of pure data mode.
> 
> I'm actually not sure if overhead is worth worrying about. On the input side, it'd be slow anyway since humans only type so fast, and on the output side if you transfer big updates at once the few bytes for length and type would be quickly irrelevant anyway.
> 
> Besides, we aren't on 300 baud serial lines!

Well, having 1 control byte per 127 data bytes is pretty good throughput in my book.

And even though we aren't on 300 baud serial lines, sometimes I *do* wanna transfer large amounts of text into a terminal as fast as I can, for example:

	http://eusebeia.dyndns.org/bashcp

Though granted, that is so rare as to be almost not worth considering. :-P


> >I'm not sure what the bash syntax is, but couldn't you just pipe
> >echo to, say, fd 3 (altin?)?
> 
> Yes, we'd just have to change the convention. I should patch vim myself!
> 
> It could probabaly be done with existing programs through named pipes too.

Hmm, good point! Though I'm not sure what will happen if you run vim on a named pipe, and it tries to mmap it. :-P


[...]
> and it occurs to me that gnu screen is, at its core, just a terminal emulator. So... having a little terminal emulation library is useful for a bunch of things - a gnu screen replacement, a customized xterm, and perhaps even my own putty program for Windows. And embedding it in programs as a nice widget to use for some gui programming fun.

And having it available as a *library* makes it very powerful -- you can use it for all sorts of things, like you said.


[...]
> >Haha, yeah. If I were doing it, I'd say just do .ttf output from the get-go, render it as an image, whatever, just don't even bother with the antiquated X11 font handling.
> 
> I thought about that, but I actually *like* the plain core font "fixed". (rxvt's default, at least on my system) I use it in a number of places and think it looks pretty good.

To each his own. I can't stand the core fonts. Esp. since they don't come in 18pt size. :-P  Which I kinda need 'cos my screen resolution is 1600x1200, and a 10-pixel-wide font is unreadably microscopic. Plus, they don't include quite enough Unicode glyphs for my needs (actually, do they even support unicode at all?!).


> To the extent that I have two xterm shortcuts: one uses bitstream vera mono and the other uses plain old fixed-14.
> 
> Oh well, I'm rendering each character individually anyway, so switching won't be a problem.

Make it pluggable. :)


> >Then when it comes time to add inline images, just treat it as a very large character with a custom bitmap font. :-P
> 
> indeed. Which brings up an idea too: you could just define custom bitmapped glyphs... arguably at this point you might as well just use xlib, but hey doing a printf("\033 magic bitmap stuff") is kinda enticing!

I remember in the old DOS days, some games would load up custom graphics into the video card's text font buffer, so that they can draw sprites just by writing the corresponding characters into the video card's text buffer.  You can get very fast drawing rates since the video card does most of the work for you (and you only need to transfer 1 byte per 8x8 block of pixels instead of 8 bytes or more).

You can even get around the multiple-of-8 placement limitation on the sprites by loading suitably shifted copies of it into the font buffer (though it does take up precious character mapping space, so you can only do that with a small number of sprites).


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis

Am 18.09.2013 22:31, schrieb H. S. Teoh:
> On Wed, Sep 18, 2013 at 03:01:26AM +0200, Adam D. Ruppe wrote:
>> On Tuesday, 17 September 2013 at 17:01:55 UTC, H. S. Teoh wrote:
>>> Actually, that gives me an idea. What if, instead of defaulting to
>>> character data, the terminal input stream defaults to control
>>> structures?
>>
>> hehe those who don't understand Windows are doomed to reinvent it :)
>> :) :)
>
> lol... though it makes me think of the latest C++ proposals as "those
> who don't understand D are doomed to reinvent it, poorly". :-P

Even though I bought the updated version of "The C++ Programming Language", I've started to get the feeling that the C++ standard might get into the same direction as ANSI Extended Pascal.

It gets updated, but besides a few places in the world, developers will eventually stop caring.

I agree with Andrei's statement at Going Native. Even if C++14 and eventually C++17 make developer's life easier, you still need to know
all archaic issues all the way back to C, to be able to tackle any issues that come up.


>
> I remember in the old DOS days, some games would load up custom graphics
> into the video card's text font buffer, so that they can draw sprites
> just by writing the corresponding characters into the video card's text
> buffer.  You can get very fast drawing rates since the video card does
> most of the work for you (and you only need to transfer 1 byte per 8x8
> block of pixels instead of 8 bytes or more).
>

In the Amiga was even better, thanks to the custom blitter chips. Just set up the required information and start a few DMA operations.

Nowadays, you can get a similar effect with a few shaders.

--
Paulo

On Wednesday, 18 September 2013 at 20:46:00 UTC, Paulo Pinto wrote:
> Am 18.09.2013 22:31, schrieb H. S. Teoh:
>> On Wed, Sep 18, 2013 at 03:01:26AM +0200, Adam D. Ruppe wrote:
>>> On Tuesday, 17 September 2013 at 17:01:55 UTC, H. S. Teoh wrote:
>>>> Actually, that gives me an idea. What if, instead of defaulting to
>>>> character data, the terminal input stream defaults to control
>>>> structures?
>>>
>>> hehe those who don't understand Windows are doomed to reinvent it :)
>>> :) :)
>>
>> lol... though it makes me think of the latest C++ proposals as "those
>> who don't understand D are doomed to reinvent it, poorly". :-P
>
> Even though I bought the updated version of "The C++ Programming Language", I've started to get the feeling that the C++ standard might get into the same direction as ANSI Extended Pascal.
>
> It gets updated, but besides a few places in the world, developers will eventually stop caring.
>
> I agree with Andrei's statement at Going Native. Even if C++14 and eventually C++17 make developer's life easier, you still need to know
> all archaic issues all the way back to C, to be able to tackle any issues that come up.
>
>
>>
>> I remember in the old DOS days, some games would load up custom graphics
>> into the video card's text font buffer, so that they can draw sprites
>> just by writing the corresponding characters into the video card's text
>> buffer.  You can get very fast drawing rates since the video card does
>> most of the work for you (and you only need to transfer 1 byte per 8x8
>> block of pixels instead of 8 bytes or more).
>>
>
> In the Amiga was even better, thanks to the custom blitter chips. Just set up the required information and start a few DMA operations.
>
> Nowadays, you can get a similar effect with a few shaders.
>
> --
> Paulo

Did someone say Amiga? :D

The first consumer PC that had a programmable GPU...with only 3 instructions.

WAIT, MOVE, SKIP.

WAIT (for the raster to reach a line)
MOVE (some data, 16-bits from memory)
SKIP (...can't remember exactly what this did, rarely used it. I think was to skip instructions in the copper list.)

On 19 September 2013 00:03, growler <growlercab@gmail.com> wrote:
> On Wednesday, 18 September 2013 at 20:46:00 UTC, Paulo Pinto wrote:
>>
>> Am 18.09.2013 22:31, schrieb H. S. Teoh:
>>>
>>> On Wed, Sep 18, 2013 at 03:01:26AM +0200, Adam D. Ruppe wrote:
>>>>
>>>> On Tuesday, 17 September 2013 at 17:01:55 UTC, H. S. Teoh wrote:
>>>>>
>>>>> Actually, that gives me an idea. What if, instead of defaulting to character data, the terminal input stream defaults to control structures?
>>>>
>>>>
>>>> hehe those who don't understand Windows are doomed to reinvent it :)
>>>> :) :)
>>>
>>>
>>> lol... though it makes me think of the latest C++ proposals as "those who don't understand D are doomed to reinvent it, poorly". :-P
>>
>>
>> Even though I bought the updated version of "The C++ Programming Language", I've started to get the feeling that the C++ standard might get into the same direction as ANSI Extended Pascal.
>>
>> It gets updated, but besides a few places in the world, developers will eventually stop caring.
>>
>> I agree with Andrei's statement at Going Native. Even if C++14 and eventually C++17 make developer's life easier, you still need to know all archaic issues all the way back to C, to be able to tackle any issues that come up.
>>
>>
>>>
>>> I remember in the old DOS days, some games would load up custom graphics into the video card's text font buffer, so that they can draw sprites just by writing the corresponding characters into the video card's text buffer.  You can get very fast drawing rates since the video card does most of the work for you (and you only need to transfer 1 byte per 8x8 block of pixels instead of 8 bytes or more).
>>>
>>
>> In the Amiga was even better, thanks to the custom blitter chips. Just set up the required information and start a few DMA operations.
>>
>> Nowadays, you can get a similar effect with a few shaders.
>>
>> --
>> Paulo
>
>
> Did someone say Amiga? :D
>
> The first consumer PC that had a programmable GPU...with only 3 instructions.
>
> WAIT, MOVE, SKIP.
>
> WAIT (for the raster to reach a line)
> MOVE (some data, 16-bits from memory)
> SKIP (...can't remember exactly what this did, rarely used it. I think was
> to skip instructions in the copper list.)
>
>

Perhaps SKIP was used as a hack to add comments. ;-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wed, 18 Sep 2013 13:31:48 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> I remember in the old DOS days, some games would load up custom graphics into the video card's text font buffer, so that they can draw sprites just by writing the corresponding characters into the video card's text buffer.  You can get very fast drawing rates since the video card does most of the work for you (and you only need to transfer 1 byte per 8x8 block of pixels instead of 8 bytes or more).
> 

That's essentially the same strategy behind the graphics hardware in
most 8/16-bit consoles. Basically the ones from around SMS/NES and then
up until 3D. You can identify them from the grid-based
layouts (which were a huge improvement, for both gamers *and*
developers over the "carefully time your opcodes to adjust the
scanlines while they're being drawn" used by Atari VCS/2600 and, I'm
guessing, probably the ColecoVision and SG-1000, which is what make
them so amazingly affordable at the time).

In DOS, a lot of CGA/EGA/VGA games used a similar approach as DOS-text-mode/NES/SMS/etc, but it had to be done in software. Obviously in those cases it didn't reduce the amount of data sent to the video card, but it did still reduce (significantly) the amount of HDD and RAM required to store the levels, and it somewhat simplified/reduced the amount of processing needed to render.

(I've done a bit of old-school homebrew, and got my real coding start in DOS VGA gaming. Fascinating and incredibly fun stuff to develop for. I'd love to design/build my own tile-based console someday, just for the heck of it.)

On Thursday, 19 September 2013 at 07:24:19 UTC, Nick Sabalausky wrote:
> On Wed, 18 Sep 2013 13:31:48 -0700
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
>> 
>> I remember in the old DOS days, some games would load up custom
>> graphics into the video card's text font buffer, so that they can
>> draw sprites just by writing the corresponding characters into the
>> video card's text buffer.  You can get very fast drawing rates since
>> the video card does most of the work for you (and you only need to
>> transfer 1 byte per 8x8 block of pixels instead of 8 bytes or more).
>> 
>
> That's essentially the same strategy behind the graphics hardware in
> most 8/16-bit consoles. Basically the ones from around SMS/NES and then
> up until 3D. You can identify them from the grid-based
> layouts (which were a huge improvement, for both gamers *and*
> developers over the "carefully time your opcodes to adjust the
> scanlines while they're being drawn" used by Atari VCS/2600 and, I'm
> guessing, probably the ColecoVision and SG-1000, which is what make
> them so amazingly affordable at the time).
>
> In DOS, a lot of CGA/EGA/VGA games used a similar approach as
> DOS-text-mode/NES/SMS/etc, but it had to be done in software.
> Obviously in those cases it didn't reduce the amount of data sent to
> the video card, but it did still reduce (significantly) the amount of
> HDD and RAM required to store the levels, and it somewhat
> simplified/reduced the amount of processing needed to render.
>
> (I've done a bit of old-school homebrew, and got my real coding start
> in DOS VGA gaming. Fascinating and incredibly fun stuff to develop for.
> I'd love to design/build my own tile-based console someday, just for
> the heck of it.)

You are not alone. These guys are still in business selling hardware just for that.

http://www.xgamestation.com/

On Thu, 19 Sep 2013 09:54:35 +0200
"PauloPinto" <pjmlp@progtools.org> wrote:

> On Thursday, 19 September 2013 at 07:24:19 UTC, Nick Sabalausky wrote:
> >
> > That's essentially the same strategy behind the graphics
> > hardware in
> > most 8/16-bit consoles. Basically the ones from around SMS/NES
> > and then
> > up until 3D. You can identify them from the grid-based
> > layouts (which were a huge improvement, for both gamers *and*
> > developers over the "carefully time your opcodes to adjust the
> > scanlines while they're being drawn" used by Atari VCS/2600
> > and, I'm
> > guessing, probably the ColecoVision and SG-1000, which is what
> > make
> > them so amazingly affordable at the time).
> >
> > In DOS, a lot of CGA/EGA/VGA games used a similar approach as
> > DOS-text-mode/NES/SMS/etc, but it had to be done in software.
> > Obviously in those cases it didn't reduce the amount of data
> > sent to
> > the video card, but it did still reduce (significantly) the
> > amount of
> > HDD and RAM required to store the levels, and it somewhat
> > simplified/reduced the amount of processing needed to render.
> >
> > (I've done a bit of old-school homebrew, and got my real coding
> > start
> > in DOS VGA gaming. Fascinating and incredibly fun stuff to
> > develop for.
> > I'd love to design/build my own tile-based console someday,
> > just for
> > the heck of it.)
> 
> You are not alone. These guys are still in business selling hardware just for that.
> 
> http://www.xgamestation.com/

I wrote three of the demos and two of the drivers that are packaged with the Hydra ;) Still have my prototype unit sitting on my desk here. Unfortunately I don't have much (any) time for hardware tinkering these days :(

Andre's old DOS-based gamedev books were key for me in going from "BASIC-hobbyist who once tried to learn C" to finally grokking C and doing more serious things.

On 19 September 2013 17:24, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> On Wed, 18 Sep 2013 13:31:48 -0700
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> >
> > I remember in the old DOS days, some games would load up custom graphics into the video card's text font buffer, so that they can draw sprites just by writing the corresponding characters into the video card's text buffer.  You can get very fast drawing rates since the video card does most of the work for you (and you only need to transfer 1 byte per 8x8 block of pixels instead of 8 bytes or more).
> >
>
> That's essentially the same strategy behind the graphics hardware in
> most 8/16-bit consoles. Basically the ones from around SMS/NES and then
> up until 3D. You can identify them from the grid-based
> layouts (which were a huge improvement, for both gamers *and*
> developers over the "carefully time your opcodes to adjust the
> scanlines while they're being drawn" used by Atari VCS/2600 and, I'm
> guessing, probably the ColecoVision and SG-1000, which is what make
> them so amazingly affordable at the time).
>

Atari 2600 was the only scanline renderer I know of from that time, and it
certainly was made to be cheap!
ColecoVision and SG-x000 were not affordable by comparison to the 2600.

ColecoVision, Intellivision, Atari 5200, Atari 7800, NES, SMS (SG-1000 and friends), Genesis, Snes, C64, etc, etc were all tile renderers, and the first 5 items in that list didn't even have scroll-offset registers.

In DOS, a lot of CGA/EGA/VGA games used a similar approach as
> DOS-text-mode/NES/SMS/etc, but it had to be done in software. Obviously in those cases it didn't reduce the amount of data sent to the video card, but it did still reduce (significantly) the amount of HDD and RAM required to store the levels, and it somewhat simplified/reduced the amount of processing needed to render.
>
> (I've done a bit of old-school homebrew, and got my real coding start in DOS VGA gaming. Fascinating and incredibly fun stuff to develop for. I'd love to design/build my own tile-based console someday, just for the heck of it.)
>

Do it, it's surprisingly easy, but jolly good fun :)

On Wednesday, 18 September 2013 at 20:33:10 UTC, H. S. Teoh wrote:
> And even though we aren't on 300 baud serial lines, sometimes I *do* wanna transfer large amounts of text into a terminal as fast as I can, for example:

actually, I do want some way to transfer files easily. Using scp and so on is kinda a pain, I would like to just

cat file > REMOTE_COMPUTER

and be done with it. scp is ok if you have keys set up on both sides and they are unix, but when you're on putty and just want to dump a file over to the Windows side, what I'd love is to hit a command and then get a save as prompt on the receiving end. Or, better yet, run a program right on it too.

If I get an email image, I want to view it or edit it, but can't really do that remotely. Even running xming, the transfer is so brutally slow (a lot of my emailed images are like 1024x4000), so I just prefer to send the compressed file over and let Windows show it natively.

Often the way I do it is to copy it over into /var/www/htdocs and then pop it open in Internet Explorer, but that's a hassle too (especially since mutt refuses to save attached files with permissions other than 600. Ugh!)

So that's something I'd do in my magic extension. Receive file from Windows, send file to it and possibly execute a command right off the bat, and probably have a clipboard interface too. (On Linux I have a program called xsel that does it. echo test | xsel, then middle click somewhere and it shows test. xsel > file, sends it out. Perfect! But X connections are kinds finicky, especially with screen where the DISPLAY isn't necessarily set right after detach/reattach.)

I'm reasonably sure there's file transfer protocols like this that already exist, but I have no idea how to use them... and hell doing it myself is easy enough.

> To each his own. I can't stand the core fonts. Esp. since they don't come in 18pt size. :-P

yeah.... I like my monitor size, high resolution is crazy!

> Plus, they don't include quite enough Unicode glyphs for my needs (actually, do they even support unicode at all?!).

not really, I don't think so anyway. They (at least on my box) have some iso 8859-1 characters, but not beyond that.


> Make it pluggable. :)

yes the way I'm doing it is there's an abstract class Terminal Emulator that does most the work and then calls a few abstract virtual functions that handles some high level stuff like redraw, change title, and then some public functions the outer class can do to drive the UI.

The abstract class also does delegates for read/write, so then I can forkpty and feed it that descriptor, or spawn a child like ssh or plink and talk to something remotely, (I hope, I haven't tried this yet, but it should work.)

> I remember in the old DOS days, some games would load up custom graphics into the video card's text font buffer, so that they can draw sprites just by writing the corresponding characters into the video card's text buffer.

god yes, and even the built in DOS graphics could be utterly beautiful. Or the OEM font as I guess it should be called. My image_basicdrawing.d embeds that font too because I like it lol.

BTW I'm pretty sure Unicode has a few user defined sections that would be ideal for this. You set a bitmap for your user defined characters and then send them right out. Though it makes me wonder: should it be a 1 bit bitmap? Or palette somehow? idk, for anti aliasing it seems to me you'd want to do a few bits that is just alpha, with the colors being defined elsewhere. But the NES had a sweet 4 color setup for its tiles!

Eh though, this is a text terminal, let's not go too nuts. The magic display image sequence can be full color.

On Thursday, 19 September 2013 at 07:24:19 UTC, Nick Sabalausky wrote:
> That's essentially the same strategy behind the graphics hardware in most 8/16-bit consoles.

Something else I love from the good old days: palette swaps. (This is why color.d, previous image.d, has a separate class for IndexedImage - it isn't a true color image with limited colors. It is a whole new paradigm with rich semantics! You can saw entry 1 == foreground and stick to that in your images and get some cool matching with the user's theme with ease.)

You could do so much with it to get cool looks, and it was fast. One of my favorite palette swap things was the old Nintendo game Dragon Warrior.

When your life ran low, it changed the font entry from white to red. But, of course, there's other places that used that entry too - the NES had only a 16 color palette (with only 4 colors per tile) so reuse was a necessity - so you'd have parts of the world changing to red too!

On one hand, that's a technical limitation, but on the other hand I thought it looked great and purposefully copied it for my 256 color DOS rpg.

You could also show/hide things by changing palette entries to be black on black, you could do transitions to night time with a palette swap, the list goes on.

I love it.