flat assembler
Message board for the users of flat assembler.

Index > Linux > Fastest text graphics for linux?

Author
Thread Post new topic Reply to topic
fpga



Joined: 22 Sep 2009
Posts: 36
fpga
I'd like to have the facility to print a character at any x and y position on the screen
with a foreground and background colour of my choice, repeatedly.

It's for simulation and I don't mind text only graphics if text only is fastest.
I just wonder if anyone knows if any one method is vastly superior to another speedwise. What's the consensus?

BTW It's svga not vga I'm interested in.
Post 29 Sep 2009, 19:24
View user's profile Send private message Reply with quote
rCX



Joined: 29 Jul 2007
Posts: 166
Location: Maryland, USA
rCX
I have a similar question. How would I print a character with a specific row, column, foreground and background color in a Linux terminal?
Post 30 Sep 2009, 02:22
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17447
Location: In your JS exploiting you and your system
revolution
Perhaps this topic would receive a better response in the Linux forum. You may want to ask a mod to move it for you.
Post 30 Sep 2009, 03:32
View user's profile Send private message Visit poster's website Reply with quote
fpga



Joined: 22 Sep 2009
Posts: 36
fpga
Will do!
I only posted here in case there was some well known os-independent asm trick to access the graphics card directly. I'm afraid I'm very weak in asm and graphics.
Post 30 Sep 2009, 06:51
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17447
Location: In your JS exploiting you and your system
revolution
fpga wrote:
... some well known os-independent asm trick to access the graphics card directly.
Well there is actually lots of code around this board that can access the display card directly but it is not suited to Linux at all. If you want direct access to the hardware in a protected OS (like Linux) then you either need to write a driver, or know how to access the existing drivers.

However, my guess, is that in Linux the console screens emulate some some type of terminal escape codes. So depending upon which terminal they emulate (possibly xterm) then the appropriate escape codes would allow you to set colours and things.

However2 as to your question about the fastest way, then this is also not the solution. As is always the case with computers the fastest way to access hardware is directly, that means with your own driver. But be sure the you really need the fastest way because it is likely to be a lot of work to gain just a little bit of speed advantage over the normal methods.
Post 30 Sep 2009, 08:26
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 454
Location: Czech republic, Slovak republic
Feryno
Post 30 Sep 2009, 08:49
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
wondering... why do you need such extreme speed?

In theory, kernel code with direct access to video HW (for flipping buffers) and video RAM should be fastest, but completely unportable to different machine / OS, probably quite undocummented, and very impractical Smile
Post 30 Sep 2009, 15:42
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
fpga



Joined: 22 Sep 2009
Posts: 36
fpga
Thankyou both for your reponses!
Because of my poor asm it's good to hear that that the gain from writing my own driver would be marginal and that most other asm options are inappropriate. That's actually very helpful.

As you know I'm already looking at the escape code method.

The dev/vcsa method (window.asm) looks promising cos they said it's DOS-like.
I saw a previous post of Feryno's and tried windows.asm but couldn't compile it.
I managed to do it this time but nothing got displayed.
Compiling seems a bit hit and miss even with the correct version of nasm.
I am intrigued by this method though.

I've got something working in Linux/ncurses but my previous work using Powerbasic/Windows API seemed faster. Does that sound right? I need to do a like-for-like test at some point cos I did add to the non-graphics functionality and went oop.

I looked at Directfb (attracted by h/ware acceleration) but had a 'mare trying to get it working.
I also tried an Svgalib eg. It compiled but also did nothing.
I'm wondering about Allegro i.e. is it fast??

If anyone has seen any more dev/vcsa demos please let me know.

I'm working towards this sort of functionality that I can call from c++
Code:
Write_chars(char[], x[], y[], fg[], bg[]){
   for(int i=0;i<no of items in char[];i++ ){
      Print_ch(char[i],x[i],y[i],fg[i],bg[i])
   }
}
    

whilst accepting non-blocking keyboard entry (I'm doing this with ncurses at present)
together with a function to clear the screen.
Post 30 Sep 2009, 17:13
View user's profile Send private message Reply with quote
fpga



Joined: 22 Sep 2009
Posts: 36
fpga
Hi Vid thanks for your comments and interest.

This is for logistical simulation (discrete event) which I've been away from for many years. Whilst you try to abstract as much as possible real world models are infinitely more complex than those used to sell such technology and even the highest end pc's were never quick enough.

My models are typically "beasts" requiring several hours to produce results informing as to what the next experimental change should be. I use the numerical output but as an experienced practitoner I can also tell much from the visual buildup of situations afforded by graphics.

Unfortunately such insight slows things down significantly. With graphics off memory bandwidth seems to be key cos you're in a big loop unceasingly moving lots of pointers around memory as directed by a priority queue scheduled by a library of inverse cumulative distribution functions driven by a random number generator. The thing runs like a chainsaw sometimes for days. You can have many thousands of parts moving around all driven by individual orders and inter-dependent rules i.e. not the same as games that lend themselves to parallelization.

If it was a word processor I'd leave it but in this case the faster the graphics and therefore speed of the model the easier it is to spot causes and trends and get the job done. Hope this explains things.

As an aside
Is there a 64-bit DOS-like OS with
support for a fast executing language + file system
fpu support for a library of inverse cumulative distribution functions (I don't want to write either)
fast high res text graphics
high memory bandwidth

BTW I don't know how to write kernel code but have put it on my list of things to look at.
Thanks once again
Post 30 Sep 2009, 18:51
View user's profile Send private message Reply with quote
fpga



Joined: 22 Sep 2009
Posts: 36
fpga
Between escape codes under Xterm and dev/vcsa this man seems to think that for his product mcl (whatever that is) dev/vcsa is faster. This tends to support the comment that it is DOS-like.

from http://www.andreasen.org/mcl/README.html
"
The fastest mode of operation is under a Virtual Console found under Linux.
However, since version 0.51.00, mcl supports normal TTY output to any
VT100/ANSI comptaible console - for example an Xterm
"


Last edited by fpga on 01 Oct 2009, 07:13; edited 2 times in total
Post 30 Sep 2009, 19:17
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
@fpga

You may want to consider how you structure your data as well.
Referring to your c++ snippet, having 5 separate arrays (c, x, y, f, b) may cause a considerable slow down in your ASM optimized code.

Using one array for your data and passing the pointer to the array to your print_ch function would be the best option.

i.e:
Code:
struct Plot
 c dw ? ;;character
 x dw ? ;;x pos
 y dw ? ;;y pos
 color dw ? ;;color 2 bytes fg|bg
ends

Array rq WINDOW_WIDTH * WINDOW_HEIGHT
;; rq = 8 bytes (the size of Plot)
    

Having your data closer together will make retrieving it faster per iteration. Separate arrays mean separate blocks of memory, so every iteration you would be retrieving code from 5 different memory blocks causing cache misses and random access vs sequential access slow downs.
Post 30 Sep 2009, 20:34
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
fpga



Joined: 22 Sep 2009
Posts: 36
fpga
That looks like very good advice. I've never handled arrays, or anything else, in asm really. A while back I looked at the standalone Forth's without the time to learn asm. Hopefully I've got a bit more time now.
Thanks
Post 01 Oct 2009, 07:09
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.