flat assembler
Message board for the users of flat assembler.

Index > Heap > how many times you scrapped your projec?

Author
Thread Post new topic Reply to topic
sleepsleep



Joined: 05 Oct 2006
Posts: 8870
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
i guess this happened most of the time as a programmer.
but does this mean, programmer are perfectionist?

and how many you scrapped your project till it couldn't be finalized and couldnt' be delivered to customer?

i was motivated to start this thread, because

bitshifter wrote:
First to make it work, then to make it work better.
Post 24 Oct 2009, 07:23
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 692
Location: Adelaide
sinsi
I have ADD - ASM Deficit Disorder. No projects, just usually someone's problem, which takes me off on tangents (e.g. a listview problem that turned into an aes thing).
The only 'project' is my own OS, but even then I get sidetracked - my latest is smp (and then vesa and the keyboard and...) ooh look sparkley stuff.

"First to make it work, then forget it because it works"
Post 24 Oct 2009, 07:33
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
This happens alot because the necessity of completing a project is often low and the number of problems that you have to deal with often increases, especially if programmer depression sets in. For example, i'm finding it increasingly harder to make a kernel when i realize that without accelerated hardware, i'll never manage to make my kernel faster or better than an existing OS which has much more speed because it's GPU does something...
Post 24 Oct 2009, 07:59
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
kohlrak wrote:
This happens alot because the necessity of completing a project is often low and the number of problems that you have to deal with often increases, especially if programmer depression sets in. For example, i'm finding it increasingly harder to make a kernel when i realize that without accelerated hardware, i'll never manage to make my kernel faster or better than an existing OS which has much more speed because it's GPU does something...


Maybe you need to look at the problem in a differant way, for example nintendo new it would lose in a high res war, So it came up with nintendo wii and its controler.
So your OS need to do the same.
Post 24 Oct 2009, 14:11
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
Maybe you need to look at the problem in a differant way, for example nintendo new it would lose in a high res war, So it came up with nintendo wii and its controler.
So your OS need to do the same.


They would'n't've lost the high res war if they would've tried. I think they just have a track record for being original. Anyway, the only benefit over a real fast linux installation is more speed or maybe better support (you know as well as i that is not going to happen). I wish i could, but no matter how i slice it, if the user does anything that refreshes the whole screen, they're gonna see the flicker. It's not hard to make up for the actual time drawing (so long as not alot of drawing is done), but my kernel isn't going to ever support basic features that anyone'll ever need in a primary OS. I'm honestly biding my time right now waiting for someone like AMD or Intel to come up with that Fusion thing and hope that the documentation isn't closed (and a dev pc doesn't get too expensive). What we need is a new standard, but too many companies are still thinking with closed minds (pun intended).

Unless you're suggesting i find a way to make my wii hardware work with my computer and make a driver. Laughing
Post 24 Oct 2009, 14:46
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
roboman



Joined: 03 Dec 2006
Posts: 122
Location: USA
roboman
kohlrak wrote:
... I wish i could, but no matter how i slice it, if the user does anything that refreshes the whole screen, they're gonna see the flicker.


If you look at my home page there's the start of a 3d graphics lib for DexOS. It stalled at the screem flicker problem. The simple answer is to draw to double buffer and then draw to the screen during the retrace. I know that, and maybe you know that and like me, you are trying to do things with out the extra memory and time hit of double buffering.
Post 24 Oct 2009, 16:24
View user's profile Send private message Visit poster's website Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
I have looked into this problem, the best way around it is to implement things like MTRR write combine, MMX etc, also look into not writing full screen, only when needed.
Example, in my GUI i save what the mouse cursor is going to draw over and draw mouse cursor direct to screen and i get no flicker, no mater how fast you move the mouse.

Also from my tests, in vesa mode, retrace makes little differance, D-buffer does.
What you need is a very fast full screen write, using MMX (or better) if available.

Also keep your game etc down to 640x480 x32 or even 16 screen res.
Post 24 Oct 2009, 17:21
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
the double buffering is not an option in graphic computing.

but instead of copying the buffer, use the VGA planes.
then, one plane ison screen, one other is edited, and when you switch planes, it is instantaneous.

there are many other techniques like DMA memoy copy, Vesa triple buffers, etc.
Post 24 Oct 2009, 19:57
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7715
Location: Kraków, Poland
Tomasz Grysztar
Dex4u wrote:
I have looked into this problem, the best way around it is to implement things like MTRR write combine, MMX etc, also look into not writing full screen, only when needed.
Example, in my GUI i save what the mouse cursor is going to draw over and draw mouse cursor direct to screen and i get no flicker, no mater how fast you move the mouse.

You may find a little more advanced variant of this technique in my kelvar engine in the Examples section (although using only 80386 instruction set).


Last edited by Tomasz Grysztar on 24 Oct 2009, 21:25; edited 1 time in total
Post 24 Oct 2009, 20:35
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Or we put our heads together and write an 82845G driver... *hint hint*
Post 24 Oct 2009, 21:21
View user's profile Send private message Reply with quote
windwakr



Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
bitshifter wrote:
Or we put our heads together and write an 82845G driver... *hint hint*


Have you ever, even once, seen the community pull together for anything other than FASMcon?

_________________
----> * <---- My star, won HERE
Post 24 Oct 2009, 21:25
View user's profile Send private message Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Ahhh, no Sad
But there are a few here that have the same dream as me...
Ive been reading the specs and it a very complex 3D chip.
Post 24 Oct 2009, 21:27
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8870
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
regarding hobbylist OS, i personally felt and believe, only those who code directly and specifically to run in virtualization (those hypervisors) will succeed & gain popularity in long run.
Post 24 Oct 2009, 21:55
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
If you look at my home page there's the start of a 3d graphics lib for DexOS. It stalled at the screem flicker problem. The simple answer is to draw to double buffer and then draw to the screen during the retrace. I know that, and maybe you know that and like me, you are trying to do things with out the extra memory and time hit of double buffering.


Actually, i've avoided double buffering because i havn't been able to get the screen a solid color without a little flicker.

[quote]I have looked into this problem, the best way around it is to implement things like MTRR write combine, MMX etc, also look into not writing full screen, only when needed. [/qote]

MTRR? Would this allow me to throw it out all at once when i'm done drawing by flushing that part of the cache but holding it until i'm ready?

I've been using slow string operations, but i figured that they're not so slow that i wouldn't still deal with flicker with simply using ecx as a base pointer and incing it. I never thought of using MMX to be honest... But how much benefit would you get from that (considering the memory bus is still limited to 4 bytes [or 8 bytes secretly on a 64bit chip])?

Quote:
Example, in my GUI i save what the mouse cursor is going to draw over and draw mouse cursor direct to screen and i get no flicker, no mater how fast you move the mouse.


I thought about that, actually since i heard that's essentually what windows does.

Quote:
Also from my tests, in vesa mode, retrace makes little differance, D-buffer does.
What you need is a very fast full screen write, using MMX (or better) if available.


Pretty much. I wouldn't mind to D-Buffer honestly (not that much extra memory at all, so i can't see why someone wouldn't want to do it).

Quote:
Also keep your game etc down to 640x480 x32 or even 16 screen res.


We might have to do just that. Right now we have it 1024x768 with 15bit colors.

Quote:
but instead of copying the buffer, use the VGA planes.
then, one plane ison screen, one other is edited, and when you switch planes, it is instantaneous.


I thought about that too, but i found the documentation a little complex. The documentation i found on it made it seem like you were writing your bytes every 3 or 4 bytes. Is this the case or i need to google up some better docs on the topic? Either way, i think i might reserve this for games anyway, because it'd be kinda fruity to constantly redraw the whole screen for anything else.

Quote:
regarding hobbylist OS, i personally felt and believe, only those who code directly and specifically to run in virtualization (those hypervisors) will succeed & gain popularity in long run.


Anyone who aims for popularity inevitably ends up in the same boat as Mac, Linux, and Microsoft (and of course the others) where people demand this and that and it just can't be provided for legal reasons or someone wants to make money or because support went down the drain. The only way you'll convince me that it's worth the power struggle is if you first convince me that i'll have half the world behind me. If you're willing to code your OS simply to be used in a VM, then you don't take it too seriously anyway. If you want to make a serious app that's cross platform (which is why you'd bother making a serious OS while worrying about virtualization compatability), you're better off with java anyway. That's why i can't see why things like VMWare and VirtualBox even succeed other than for people who absolutely must use two OSes on 1 computer at the same point in time (and can't use cygwin, wine, etc).

Anyway, thank you all for your tips... It seems there's alot i havn't considered yet.
Post 25 Oct 2009, 11:07
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
It's human nature to get bored and "scrap" projects sometimes. It's a lot of work! And sometimes the benefit is little. That's why there are so many emulation efforts in various forms (Cygwin, WINE, DJGPP, NTVDM, DOSBox, DOSEMU, VirtualBox) ... people don't like being forced to throw away their efforts. All software eventually depreciates in value (apparently), which is kinda sad. I guess I'm just really jaded because I see ads for things (Win7, XBox 360) whose predecessors I still remember, and yet even these "new" things will be considered obsolete and abandoned in a few years. It almost makes you think: why bother?

And that brings me to the point of this message. Program for fun, enjoy what you're doing. It doesn't matter if it's obsolete (*cough* DOS, my favorite) and nobody uses it, it only matters if you enjoy it.

In other words, don't waste time programming for some arcane video card unless you personally think it's worthwhile and enjoy the experience. Otherwise you're wasting your time (even if you get paid).
Post 25 Oct 2009, 11:49
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
I think that writing 2D driver with HW cursor support for Intel graphics wouldn't be THAT hard. Just take a look at X.org driver - it isn't THAT complex.
Post 25 Oct 2009, 12:06
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
Tomasz Grysztar wrote:
Dex4u wrote:
I have looked into this problem, the best way around it is to implement things like MTRR write combine, MMX etc, also look into not writing full screen, only when needed.
Example, in my GUI i save what the mouse cursor is going to draw over and draw mouse cursor direct to screen and i get no flicker, no mater how fast you move the mouse.

You may find a little more advanced variant of this technique in my kelvar engine in the Examples section (although using only 80386 instruction set).

Thanks Tomasz Grysztar i will take alook.

@kohlrak, Give a simple example of what you think can not be done in vesa and at what res, and we can try and show you its posable (unless your talking high end 3d call of duty).

Making a 82845G driver
I had a quick look into the 82845G driver datasheet, i have written many drivers, but from my quick read it seem to work more at a higher leave, almost like calling a C function, which put me off, but i may not of given it a chance.
Post 25 Oct 2009, 13:57
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 can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.