This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - rwill
16
« on: May 18, 2015, 09:35:12 am »
For easier comparision, here are the two inner loops of drawSprite and the nGL equivalent, compiled with the same flags as your example:
... As that code is run per pixel, I guess that that is definitely a noticable difference.
Sadly both routines appear to be quite unoptimized.
17
« on: May 14, 2015, 07:07:27 am »
I think I scared him
18
« on: April 19, 2015, 12:25:32 pm »
Textures are always a big deal with calculator 3D engines, because they require a loooot of processing power. As far as I know, the only engine that's fast enough to provide textured polygons is nGL on the TI-Nspire because this calc has a lot of processing power actually.
Well "someone" ported Quake to the Nspire and it was kinda fast enough. When completely implementing from scratch for the Nspire, like taking the lack of floating point hardware support into account, the relatively excessive amount of memory and the somewhat modern ARM architecture one could even do faster than that. But this is the 68k board, the Motorola 68k CPU was released in 1979... see attachment. Since it's a portal renderer, if the portal isn't visible, whatever's on the other side isn't either. [...] I wonder if there's a way to efficiently programmatically determine potential visible sets...
You can precalculate the PVS for a cube to generate an array of bit flags representing the other cubes visibilities for that cube. Quake did that and I did that in Delsgolf. For the cube you want to generate the PVS for you just generate planes with the cubes on the way to the target cube and clip the target cube by the planes. Clipped target cube == not visible. Details are somewhat delicate but explained all over the internet.
19
« on: July 12, 2014, 02:23:36 pm »
Thanks rwill! Unfortunately, the quotation marks seem impossible to write in the console.
EDIT: Nevermind, it works now without entering any command! EDIT2: I suggest to enable the touchpad so that the user doesn't have to click, juste as in nDoom. And scratchpad/doc for move on the right and on the left instead of the decimal point? And an other key than the space to jump.
Uh... now you have to explain to me which console you tried to type the quotation marks into.. because I intended to have nquake.cmd.tns to be constructed on the host PC with a text editor ( without a newline at the end of the command line, thats missing from the readme.txt ) and then just uploaded to the calc. Remember I am a Nspire newbie. Regarding the touchpad, for me it is a pain to play nDoom without mechanical feedback ( the click of the arrow keys ). Like I barely touch anything and the player begins to move.. I do not like that at all. I will add the scratchpad/doc keys for keypress evalutation though.
20
« on: July 12, 2014, 06:18:09 am »
rwill : could you make it not mandatory to put the file in the folder "id1"? The duration of opening "My documents" inscreases with the number of folders.
(Moreover, I can't put files in a subfolder currently, so I can't play to the game)
I am sorry, I was not aware of the problems Non-Windows users are faced with when uploading files to the Nspire. So I attached a new Release Candidate to this post that lets you specify command-line options. Please see the included readme.txt for instructions on how to change the game directory from "id1" to "".
21
« on: July 09, 2014, 03:13:18 pm »
And there's still more to optimize. Partial loop unrolling as 2x16bit access is slower than 1x32bit for example.
To give you an example of a almost fully optimized function, I optimized drawTexture some more: https://github.com/Vogtinator/crafti/blob/master/texturetools.cpp#L151 GCC does some partial unrolling, but doesn't transform 2 16bit accesses (ldrh/strh) to 32bit access(ldr/str), although -Ofast should do something, should I report a bug?
8e28: e15392b4 ldrh r9, [r3, #-36] ; 0xffffffdc 8e2c: e14292b4 strh r9, [r2, #-36] ; 0xffffffdc 8e30: e15392b2 ldrh r9, [r3, #-34] ; 0xffffffde 8e34: e14292b2 strh r9, [r2, #-34] ; 0xffffffde There are actually two reasons why a compiler cannot use 32bit memory move instructions here. 1: COLOR *dest_ptr = dest.bitmap + dest_x + dest_y * dest.width, *src_ptr = src.bitmap + src_x + src_y * src.width; dest_ptr might be src_ptr + 1 ( *src_ptr is not const ) so moving two texels for this case will produce different results. 2: It is not guaranteed that src_ptr and dest_ptr are each aligned to 4 byte which is required if you want to move 4 byte at a time on ARM.
22
« on: July 04, 2014, 03:55:11 am »
So I did some more optimizations and submitted it to ticalc.org as I was able to play through the first episode without noticing anything wrong. ExtendeD: A problem I noticed with Ndless 3.1 in the emulator is that the stack was not aligned to 8 bytes upon entry of main() which leads to failure of functions taking 8 byte datatypes. ARM EABI requires the stack to be aligned to 8 byte. I worked around that by aligning the stack myself so printf and the likes work. This could be related to http://www.omnimaga.org/calculator-c-language/nspire-printf-syscall-is-not-ansi-compliant/ as I got the same symptoms. I have not tested with Ndless 3.6 or on the real HW.
23
« on: June 27, 2014, 12:30:46 pm »
New build. I fixed the system error message so you can exit graceful by keypress instead of having to reset. I also changed the keypad read routine for the touchpad which gave some speedup. I also added more keys for interpretation.
I also noticed that I never explained the key bindings. For the game you can bind any key nQuake understands. You can set these through the menus.. ESC opens the menu which you can navigate with the arrow keys. Enter goes to a sub-menu and ESC returns from it. In the sub-menu Options is "customize controls", if you select that you can remap all in game actions to different keys. nQuake currently understands the following keys: Arrow Keys, A-Z, 0-9, SPACE, TAB, CTRL, SHIFT, SPACE, +/-/=, TRIG, ^, X^2, e^x, 10^x, (), .
The Quake console is bound to the "?!" key. There you can type commands like "map start" or "timedemo demo1" and other stuff from the 90s.
I included the Windows Visual Studio solution this time because its where I do development so it kind of belongs in the package.
24
« on: June 27, 2014, 03:38:26 am »
mdr1: Well it should look something like in the attached picture:
25
« on: June 26, 2014, 09:06:19 am »
Vogtinator: The assembler file is missing the following comment because I am not quite done yet: @ Division routines are implemented with using the book @ "ARM System Developer's Guide: Designing and Optimizing System Software" @ by Andrew N. Sloss, Dominic Symes, Chris Wright @ as a reference. @ I am not good at math The division routine is called _incorrect because I removed the error correction of the quotient and remainder at some point but added them back later because of.. issues. So it is actually providing correct results. If you are interested in the mathematical proof and more ARM optimizing shizzle I strongly recommend the book. Speedup is significant if you have to do a division every 8 pixels. DJ Omnimaga: I do not know if it runs on 3.1. My emulator setup is 3.1 and my calc is 3.6 and it runs in/on both. mdr1: Quake cannot find the pak0.pak(.tns) in the /quake/id1/ folder. Are you sure its there ? I identified the reason you had to reset instead of just having to press a key so thank you for your feedback
26
« on: June 25, 2014, 04:10:26 pm »
-- Development Update -- Although I have run my fair share of tests it would be cool if some other people can test it and report any errors found. Like graphical errors or crashes. So if someone wants to test it here is a current build + sources. You need a CX to run, non-color nspire wont work. In addition to the quake binary for the nspire you need at least the shareware data file pak0.pak. This is kind of hard to get when not running MS-DOS and one wants to honor the license so I deliver instructions: -- Begin of Instructions of how to get the Shareware pak0.pak -- Get the quake shareware release quake106.zip somewhere of the internet. One place is here: ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/quake106.zipInside the quake106.zip is a file called resource.1 - Extract it and rename it to resource.x Get the LHa compression/uncompression utility. For Unix ask your packet manager. On windows this is somewhat hard but you can get a binary release here: http://gnuwin32.sourceforge.net/packages/lha.htm ( Binaries, the lha.exe inside the .zip is in /bin ). I read somewhere that the japanese Windows 7 gets it as an addon for the file explorer so you can also try that. Move resource.x to a temporary directory and extract it. On windows you can do this with "lha x resource.x" if you moved lha.exe to the same temporary folder or lha.exe is in your $PATH. This hopefully creates a lot of obsolete files and a directory called "id1" which contains "pak0.pak" You can also get Quake off Steam or so I heard. -- End Of Instruction of how to get the Shareware pak0.pak -- MD5 Sums of the quake data files pak0.pak 5906e5998fc3d896ddaf5e6a62e03abb pak1.pak d76b3e5678f0b64ac74ce5e340e6a685 ( registered version ) On the calculator you need a directory structure like so: quake/nquake.tns quake/id1/pak0.pak.tns quake/id1/pak1.pak.tns ( optional, if you bought Quake and got the pak1.pak file of the registered version put it there ) Then run nquake.tns
27
« on: June 16, 2014, 03:58:34 pm »
This is looking awesome. Welcome to Omnimaga!
Ninja edit: Is that Quake?
Yes it is Quake. I kind of overestimated the speed of the Nspire CX though so it will never run really fast i guess. TI calculators do not seem to follow Moore's law.
28
« on: June 15, 2014, 02:25:20 pm »
Are you using nGL for this, or some other libraries?
I am using the original WinQuake sources as released by id software without any additional libraries.
29
« on: June 15, 2014, 01:37:33 pm »
So with the recent release of ndless for 3.6 I have chosen to aquire a TI-Nspire CX and do some programming.
To get a feeling for the platform I have further chosen to port some first person shooter from 1996 and in nspire_emu it runs pretty well. However on my OS 3.6 Nspire CX CAS it first did not run at all and once I removed all printfs it ran but was kind of slow compared to nspire_emu. So I have some questions ..
1. Does it matter if I try to printf to the console ( serial port ? ) and there is no receiver connected ? From my program failure it appears so but I rather have the printfs() in so I can debug using nspire_emu. Are there other pitfalls that do not occur in nspire_emu but do on real hardware that can cause something like this ?
2. Either my Nspire ( hardware revision M ) is slower than normal Nspires or nspire_emu is faster than the actual hardware. As with porting some game most time is spent adapting to the new platform ( read optimizing ) I am wondering if nspire_emu is even cycle accurate or if I can only rely on benchmarks run on the real hardware.
So this is all that is going around in my head now.. I'll try to attach some photo to show my current progress.
PS: To skip my introduction in the introduction board I am the guy that did that Delsgolf FPS for the TI-89 last year.
*edit* Changed Title
|