1. draw_line()
- Posted by Lucius L Hilley III <luciuslhilleyiii at JUNO.COM> Jun 27, 1997
- 653 views
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.
2. Re: draw_line()
- Posted by Ralf Nieuwenhuijsen <nieuwen at POP.XS4ALL.NL> Jun 27, 1997
- 635 views
> 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
3. Re: draw_line()
- Posted by Anders Eurenius <c96aes at OXE.CS.UMU.SE> Jun 28, 1997
- 652 views
> > 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 --------------------------------------------------------------