Software Rendering.

[Clyde]

As you know i've used TinyPTC for a lot of my coding adventures mostly FreeBASIC works, and I wanted to ask if by using tinyptc, does that still count towards software rendering? Or is that leading towards Hardware?

I know that during the age of Blitz Basic, even though it used DirectX to draw with, people still used the phrase "Software".

Is it one of those terms that mean different things to different people?

I want to continue with tinyptc as it's better than GDI, but am a bit concerned when releasing something in C++ that people will start to say why is a hand coded software demo using Direct Draw. Or would you turn the over cheek.

[Jim]

Software.  If you're manually filling a framebuffer with pixels it software, even if there's a hardware accelerated step in getting the framebuffer to the display (ptc_update in this case).  I don't count it as hardware rendering unless you're drawing triangles or using pixel shaders.

Jim

[Clyde]

Thanks Jim!
It's along the lines of what I thought too.

[spitfire]

GDI isnt any more low level than directx

[Shockwave]

GDI isnt any more low level than directx

I dont think Low level or high level has much to do with software rendering, if you write your own routines to draw text, polygons, sprites it's software rendered.

If you used opengl or directx to render pixels as small quads, it's still software rendered as far as I am concerned because it's your custom written functions that are used to create the polygons, lines or whatever else you make.

low level and high level language refers to how much like english a command set is.
At it's lowest level, programs are binary patterns, the higher the level of language, the more readable to humans it becomes.

You could use assembly language to invoke opengl or directx function calls, similarly you can use the same language to open a window and plot pixels onto it by writing into screen memory.

Therefore software rendering must mean manually writing pixels into some kind of display buffer.

[spitfire]

I wasn't talking about software renering.

High or low level to me is an indication of how many levels of abstraction exist underneath the technology, how many API's your function call is going through for example. So theres no reason for anyone to think directdraw is any less hardcore than GDI.

Java and .net on the other hand, is for poofters because everything they do just calls chains of other APIs functions

[Shockwave]

Let's not degenerate into bashing languages please.

[Stonemonkey]

I realise that doing all the pixelwork into a screenbuffer is software rendering but say someone releases a demo into the demo community stating that it's software rendered which then turns out to not work on particular machines because the method of displaying the screenbuffer uses some harware feature or it shows up in fraps or some other hardware related software?

IMO you could be opening youself up to comments like 'this is supposed to be software rendered so why do I need gfx acceleration?'

[Jim]

Java and .net on the other hand, is for xxxxxxxx because everything they do just calls chains of other APIs functions

Just for that, I'm going to write my halloween demo using software techniques in C# 

Jim
 

[spitfire]

Showckwave: It was meant tongue in cheeck

Stonemonkey: Directdraw doesnt need any hardware acceleration, but I do see your point. Using opengl for software rendering seems "unpure".

Jim: what are you revealing about yourself there buddy

[Jim]

what are you revealing about yourself there buddy?

That being narrowminded about programming languages won't get you anywhere

Jim

[Stonemonkey]

Can the use of any hardware method of displaying a screenbuffer result in smoothing or anti-aliasing of the output?

[Shockwave]

Can the use of any hardware method of displaying a screenbuffer result in smoothing or anti-aliasing of the output?

Yes, I have had this problems myself with Opengl and tinyptc (windowed mode) there are ways around it though.