1. draw_line()

draw_line() is a very simple and easy to use procedure.
Could someone create a draw_line2() for me?
I don't get much time to create lately.
I can do it but I would appreciate the help.
draw_line2() should work identical to draw_line()
draw_line2() should make full use of pixel()
Please NO direct screen writes.
I will be porting the code into screen.e
a Joint effort to make outstanding graphics support
in mode 19. 320x200 256 color.

I have a vpixel() routine the works indentical to
pixel() only it allows me to write to some virtual
screens.

Thanks in advance Lucius L. Hilley III

--Lucius Lamar Hilley III
--  E-mail at luciuslhilleyiii at juno.com
--  I support transferring of files less than 60K.
--  I can Decode both UU and Base64 format.

new topic     » topic index » view message » categorize

2. Re: draw_line()

> draw_line() is a very simple and easy to use procedure.
> Could someone create a draw_line2() for me?
> I don't get much time to create lately.
> I can do it but I would appreciate the help.
> draw_line2() should work identical to draw_line()
> draw_line2() should make full use of pixel()
> Please NO direct screen writes.
> I will be porting the code into screen.e
> a Joint effort to make outstanding graphics support
> in mode 19. 320x200 256 color.
>
> I have a vpixel() routine the works indentical to
> pixel() only it allows me to write to some virtual
> screens.

        I'll work on it, it shoudl be fairly easy,
        Just have an horizontal step and an vertical step.
        (With 4 different 2nd pixel placings)

        Well, the routine will be finished tonight, i already have a
c-version of it somewhere and even a tutorial.. (Aspherixa
tutorials)

        About your screen.e, here's an 25% done version of my gfx.e
        It handles 3 types of virtual screens (memory, one long sequence
and an image sequence)
        The routines look big, but only a very small part is executed
each time. Only depending on the situation which part.
        Exemple: both screeens are memory screens and i want to copy one to
another, both views are maximized too (that is 1,1 to 320,200), a
a simple mem_copy will do al the work
There's a video-mode database included and routines that search
                for
a mode with given sizes (min & max) and given number of colors and
palletes. All routines will work with text too.....

        The Monitor sequence is an virtual screen handle too, but it's
the handle for the real screen, a virtual screen handle holds a
information about the screen, such as the type, the addres
(sequence handle or memory addres), the size, the length (is the
size multiplyed, but here for speed), and the view (which is the
part of the virtual screen where is read from and writtin too.
        Mode 19 will set the addres in the monitor sequence to #A0000, and
type to Memory. Mode 256 will set the type to PIXEL, a special
type for the monitor.

        Because of this system, text is also available (as long as you can
write to the video memory of it)
        The database of video modes will all information is in a differetn
file: ALLMODES.E
        So it can be updated seperately.

        I also have a nifty sprite technique... (compiled sprites)
        Which writes whole rows of pixels in once, with no extra overhead,
on a screen (and thus also the screen: Monitor)
        And NO position calculation, we simple add the screeen width for
each movement down!!

        I have it all figured out already, just have to code and debug.. :)

(He, also text-mode sprites are available then, because of the great
flexibility)

        Maybe you some people can  help me, if you understand most of my
intentions...

Ralf Nieuwenhuijsen
nieuwen at xs4all.nl

new topic     » goto parent     » topic index » view message » categorize

3. Re: draw_line()

> > draw_line() is a very simple and easy to use procedure.
> > Could someone create a draw_line2() for me?

> > a Joint effort to make outstanding graphics support
> > in mode 19. 320x200 256 color.

320x200x256 is sucky! gimme 640x400x256 or something!
(Oh yeah! How do I screw around with 65k? 16M? )

> > I have a vpixel() routine the works indentical to
> > pixel() only it allows me to write to some virtual
> > screens.

Uhh? (Oh yeah, maybe mode 19 has more pages (my 257 tells me it has 1))

>         I'll work on it, it should be fairly easy,
---8<---
--->8---
>         I also have a nifty sprite technique... (compiled sprites)

Like, hellooo?! don't tell this sucky box doesn't have hardware sprites!
(Moveable graphics-objects that don't destroy the picture)

>         Which writes whole rows of pixels in once, with no extra overhead,
> on a screen (and thus also the screen: Monitor)
>         And NO position calculation, we simple add the screeen width for
> each movement down!!

Uhh? what? What calculations *are* you making exactly?

(I came this close () to asking you about screen modulo and stuff like that.
Then I remembered: PC, not Amiga; Hello, sucky architecture!)

>         I have it all figured out already, just have to code and debug.. :)
>
> (He, also text-mode sprites are available then, because of the great
> flexibility)
>
>         Maybe you some people can  help me, if you understand most of my
> intentions...

I'd love to help, but I'm sorry, I just don't get it! (plz xplain!)

> Ralf Nieuwenhuijsen <nieuwen at xs4all.nl>
Anders
--------------------------------------------------------------
Anders Eurenius <c96aes at cs.umu.se> ICQ UIN:1453793
Computer Science/Engineering student at the university of Umea
--------------------------------------------------------------

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu