What you have to save is data memory, not code memory. You have plenty of such.
Anyways, it was just a hint to make your engine faster. You may take it or not.
Quote:Anyways, it was just a hint to make your engine faster. You may take it or not.
Heh, obviously you don't comprehend all that you read... J/K :lol:
READ MY POSTS!!! I DID CONSIDER IT!
(Actually I reconsidered...(Sting space was more of an issue than speed in this case, but ultimately when reconsidered, I used both
mine and yours ideas... SEE THE CREDITS!)
See, I always code in a matter that will utilize the best optimizations where and when needed, so you can have many optimization options at times. When you take all these ptimizations and weigh their total benifits towards what your routines main goal is then you might end up doing something similar to what I did here.
Bye.
Nemesis
WHOA! What happened here while i was away!
(Sorry, i can visit the Web only 2 times in a month...)
I will download these and take a look at it. Now i had not got enough time to read it: it is after midnight, and Internet is not cheap...
(I just had seen one from Nemesis: Chain4 256 color modes are completely different from usual 16 color modes. They need a really different technique)
So now only what i wrote in Notepad (based on what i had seen here 2 weeks ago...):
Quote:Nemesis:
You was really right with POKE. It was strange for me that i got at around
110FPS with it since i was given up SCREEN 13 in QB far away in the past
exactly because i could not write a fast POKE based pixel - plotter for it
(On the same computer on wich i tested now). But it is true too that my
HLine sub runs nearly two times faster in ideal situations so to fill large
areas (what is needed many times) it is much better to use my HLine instead
of anything else (If the programmer wants to clear a memory page, not the
screen itself).
Now i think the best solution is to merge our libraries, and create a long
integer based memory page on which pixel plotting goes with POKE, but
filling certain areas being wider than 20 pixels goes with my HLine sub.
It would be not easy to create a similar thing for LONGs to HLine, and due
to many calculations it might lose some speed: i can not say anything about
this since i did not try it yet. But if it can be well written i except at
about three to four times greater speed than usual POKE when clearing the
entire memory page (On the other hand just for clearing it not too much is
needed: just a FOR cycle what runs from the start to the end. But many
times some big solid shapes like rectangles are needed what is only
possible with building up from a similar algorithm to HLine).
To create a HLine for long integer array i has got some ideas already since
i wrote a sub what achieved the same for 16 color screens. I did that
because it really annoyed me that QB is so slow with that, so i tried to
outperform it by creating a sub what does not need to access the VGA ports:
instead it just drew on the currently set page so i could collect some
lines before sending them to the VGA in one cycle. I failed with it yet
since the drawing algorithm was much slower so the overall speed was around
the same as usual QB lines.
I red what you all wrote here: it is really true that pure QB SCREEN13 libraries are out of date as the whole thing. I always would like to program retro in real mode using C or sometimes assembler, but that would have not been understood by anybody... Or i simply would not be able to post and talk about or compete with those sources anywhere as nobody is really interested in them. So QBasic. Here i got annoyed that everyone programs in QB, but they actually use tons of ASM or other languages, and just merge the results with QB. This is why i like to write here: if QB, do it perfectly without messing with anything else!
SCREEN 13 library: my comcept was to write a small library what supports only the most important features of graphic. I think more is not really important since it would just waste the code space for most of the programmers who not really need the extended features. And usually who gets a lib not tries to cut it in parts when she or he not needs some, just gets annoyed if the program won't compile because of it's size. In my opinion "most important" is a pixel plotter, a screen clearer, a PUT routine supporting transparency, and a fast hline sub to build up filled rectangles or triangles for 3D from it. Of course this all on one, or more not visible pages which can be sent to the screen when drawing is finished on them.
heya,
hmm, since i'm finishing my ninjanight game at the moment i guess it'd be a good opportunity to post the pure qb demo of the game here:
http://people.freenet.de/mariuz/junk/demo.rar
the complete game will also be mostly pure qb.
cheers
If you were waiting for me, and for new ideas for Screen 13, sorry: it appeared that because of certain reasons i have no time to program in QBasic for a while. But i do not want to leave you and the challenge here with this: if you want, take a look at the QB screen modes topic in "QB in general" (It has some crappy name what i can not remember now). There ask Adigun (Our web page completely broke because of our only computer from which we could update it not works) for my newest program, and you will see the subject of a new competition
(I told this especially to Nemesis: you would certainly be interested)
Hmm... unrolling code...
Shouldnt the compiler do that for you?
So if i have a sub that is a one-liner, the compiler should put the one-liner in case of the CALL.
Ok, on today computers it dont matter, because most opcodes are executed parralel. So i can push something on the stack and at the same time set the CPU-ProgrammCounter to a new point in address space.