Message board for the users of flat assembler.
> OS Construction > OS-like game in development, FASM MBR examples appreciated
Goto page Previous 1, 2
itsnobody 26 Mar 2008, 20:17
video ram = 1MB ==> if pixels are 32 bits leng, then, up to 256K pixels, then, 256*1000, it's more than the PS resolution, so, you can memorise more than one screen. to increase the speed. triple buffer???
Right, OSes Like Windows are designed for multi-tasking and other things that slow everything down dramatically, where as the PSX OS was designed just to run a game and do nothing else...so whatever game you're making, if the OS is designed just for the game itself, it should run very fast without much memory requirements...
|26 Mar 2008, 20:17||
edfed 26 Mar 2008, 21:15
i'm pretty sure that OS will die one day
why os if the boot lets place to a good application?
|26 Mar 2008, 21:15||
Azu 01 Aug 2009, 02:06
For multi-tasking, apparently. But then again, hypervisors fill that role more efficiently.
|01 Aug 2009, 02:06||
mbr_tsr 23 Aug 2012, 13:28
Make a Germ chase Row Col Flee/Chase balls to Get in DNA Kode http://www.members.tripod.com/cpu_bios/OUTPUT.WPP Make it in WackyPlusPlus W++ WALCULUS
|23 Aug 2012, 13:28||
freecrac 24 Aug 2012, 06:42
It is not a problem to use the (E)SP register as a placeholder for temporarly values.
Beginning with to store the value of the (E)SP register into a specified ram location,
using the (E)SP-register for to temporarly place some values inside and if we done,
then we have to reload the (E)SP-register with our stored value from our specified ram location.
While we using the (E)SP-register for other things we can´t use our stack, example for to push/pop values or for to calljump into a subroutine.
(For to prevent of uncalculating behaviors if the stackpointer let push values far outside of our stack.)
Additional we can use temporary unused segment registers in the same wise and the first 4 debug registers can also be used as a placeholder for values (and/or for to prevent to debug the code).
It is possible to write a bresenham line routine without to store interim results of our calculation into the lazy ram using only cpu registers at runtime instead.
(It is not the first posting, please scroll down this page.)
This routine is written for to use the linear framebuffer with an 8 Bit color mode using 255 colors and for using the 16 bit Unrealmode/Big-Realmode.
And this line routine use a table of startadresses of each horizontal line of the screen and this table starts at the beginning of our data segment.
With this table we can use the Y-corrdinate (exacly a muliple of this value related of the addresssize of each entry/record in this table) as an index inside of the table to get the line address of the framebuffer.
Additional we have only to add the X coordinate
(or a mutilple of this value ralated on how many bits per pixel we are using, if we modify the code for to use 16 bits or 24/32 bits per pixel.
Note for to modifying this code: There are more than only one mov-operation to write a pixel to the framebuffer).
|24 Aug 2012, 06:42||
|Goto page Previous 1, 2
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.