Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: theUnnamed on May 07, 2010, 08:19:34 pm
-
I had a crazy idea. Builder boy wrote portal X to run at 9fps on a z80 running at 15mhz and with 24kB of ram. Well the N-spire has 90mhz processor, 32MB of ram and an OS that is a million times more intelligent than the TI 84's. (nucleus itself not the TI front end) to put things in perspective the N-spires processor it clocked 18 times faster then the 84 and is a better architecture plus its 32 bit as opposed to 8 bit we are talking around 50 times the computational power of the 84 and over 1186 times the memory. with this kind of memory it should be possible to write a full 3d portal running at 30 fps interlaced. (because the screen is fine enough that it can be gotten away with)
To give a comparison the Nintendo DS has about the same if not less processor power, spread across to processors so there is extra overhead of coordination, then the N-spire and one 4mb of ram + 656k of video ram to the N-spires 32MB (including OS space). 3d rendering a physics are completely possible on the N-spire and portal is only a tiny bit of a strech
-
DS has a fairly advanced GPU in it (doesn't compare to a modern iPhone of course, but the DS is kind of old). 3d isn't as fast as you think it would be when you don't have a GPU doing all the work.
Also, interlacing apparently isn't supposed to be used on LCDs.
-
the only thing the ds has on the nspire is the video ram and plus bwag's already got a raycaster
-
the only thing the ds has on the nspire is the video ram and plus bwag's already got a raycaster
Oh, you want to do Portal with a raycaster? I'm not really sure how that would work.
-
I'm not sure my raycaster can handle scenes of that complexity and still run at reasonable speed :(
The DS has more that just video RAM; it also has an entire GPU doing the 3D transformations and texture mapping.
-
Yea, you have to remember even with all that horsepower the Nspire isn't a dedicated gaming machine. Without a GPU to handle all the 3d stuff that means your CPU has to do everything.
*edit* Beat me to the punch!
-
portal plus raycasting might be a bit hectic to make, especially when shooting portals on the floor. I think you wouldnt even be able to see through portals until you get through it (you would then be warped on the other side).
As for the FPS, it would also need to be dropped to like 15 FPS because the Nspire LCD is too blurry to have anything of higher FPS look good. When turning around in Bwang's raycaster, we have trouble seeing stuff if we're viewing an area that renders very fast
-
Hmm, I actually do wonder if interlacing could be used to give the illusion of twice the FPS (since every other line of the screen would be updated every other frame, it wouldn't have increased blurriness in theory)
-
I actually thought about interlacing the other day. It could maybe work, actually, and speed things up a lot.
-
What do you mean by interlacing? Do you mean draw different sets of columns every other frame (so this frame I'd draw columns 0, 2, 4, ... and next frame I'd draw columns 1, 3, 5, 7, ...)?
-
What do you mean by interlacing? Do you mean draw different sets of columns every other frame (so this frame I'd draw columns 0, 2, 4, ... and next frame I'd draw columns 1, 3, 5, 7, ...)?
Exactly.
-
Just random, but on topic question kind of, but what if you "MacGyvered1" a GPU up to the Nspire? (In theory.)
1: For those of you who don't know who MacGyver is he is a person from an old TV show who would put together odd contraptions, out of random things around him, to get out of a tricky situation. Ex: Use gunpowder to open a locked door (as tested on MythBusters :P).
-
kinda like old TVs
-
you are totally wrong about the way the DS it does ALL of its 3d rendering on an ARM9 clocked at 67 MHZ the N-spire is running an ARM9 clocked at 90 MHZ
from Wikipedia:
CPUs: Two ARM processors, an ARM946E-S main CPU and ARM7TDMI coprocessor at clock speeds of 67 MHz and 33 MHz respectively. The ARM946E-S CPU processes game play mechanisms and video rendering while the ARM7TDMI processes sound output, Wi-Fi support and additionally, when in Game Boy Advance mode, processes what the other processor used to do.
The DS has no vector coprocessor to speak of sorry to disappoint its just got an efficient engine.
the DS and n-spire use 2 different breeds of the ARM9 the N-spire using the highest end that has special instructions for JAVA optimization and the DS uses the second to highest end that may have more cache. I'm almost positive this can be done.
as a note:I mentioned the ray caster because it showed that such things could be done. To do portal one would of course need to optimize the hell out of the current ray caster or write a rasterization rendering engine
-
It would still need to use something else than raycasting, though. I am uncertain raycasting can be vertically wire-frame. Just see in old versions of Bwang raycaster how distorted things can get when looking up/down very high/low.
Basically real 3D could be used. real 3D would be possible, too. With several polygons, Calc84maniac got about 70 FPS on his 3D wireframe engine. That was without textures and polygon sorting, though, and I think the engine is discontinued.
I would like to see more Nspire 3D dev in the future, even if Ndless 2.0 was to be discontinued or end up unavailable forever, because there's lot of potential
-
I wrote a response 2 days ago and apparently it didn't take so now I'm here typing it again. sigh. at least I have a real keyboard this time (typed last one on touch screen keyboard phone) I agree if it were to use real 3d and textures and poly counts were carefully managed a full 3d fps should be "easy". I put easy in quotes because writing a 3d game engine is a rather large under taking. portal would have to be a slightly longer range goal for the engine. one would build an fps first then modify the physics and rendering engines to manage portals. portals represent a difficult rendering challenge valves portal as I understand source may have to render the world up to 5 times (default render depth of 2) in various resolutions to get an image so if possible a better way should be found (the engine has a hell of a time trying to render multiple sets of portals that are in the same room. there is a reason only one set of portals is allowed at a time. again that's if i understand correctly.)
Though the engine would have the advantage of only having to render in 4-bit grey-scale on a 32 bit processor and there for with some careful register games work addition on 5 pixels at a time and multiplication of 3 in single ops. (rough guess haven't worked it out yet I need to do some looking up on the architecture.) rendering still will represent likely over 60% of the CPU time and will have to be hand optimized in many places (because you can't always trust compilers to tile the best way possible. Memory is also a little bit of a problem because modern day engines tend to get their speed by having half of the stuff pre-rendered by the developer and pre-rendering can make things gigantic fast. listening to developer commentaries valve seem like their jumping through rings of fire bare-foot backwards on a unicycle while playing a piano and a harmonica to so that they don't blow their memory space. I exaggerate only slightly. (they really wear shoes. those petals are ruff on the feet.)
I would like to note that this is not an undertaking I think anyone should try to solo this should be worked on by a team of the best coders on this site and a good high level design before they start. I know I'm not willing to take this on alone
As a final note: I only used portal as an example because i thought it would get the best community response. I just really what to see a 3d game engine once that code base is in place it can be easily built off of to make many games.
-
Ouch I hate when I post and message won't make it through x.x. usuallY i just forgot to click "Post" x.x
As for portal, I think render depth should be 2 max, because then it would slow things down a lot. Maybe in the portal, the quality should be decreased as well for higher performance.
Also if it's a team project, I think the source/files should be put somewhere all members can access, and backed up elsewhere in case a member went nuts or stole everything. I say this because in the 9 years I've been doing calc stuff (almost), I saw many team projects die because one member vanished completly, taking his portion of the code (or files) with him and the team member and his work was irreplaceable. Also each team members needs to agree on the project goals. Else it ends up in an endless debate. This is why nowadays you barely see any team project anymore in the TI community.
-
you are totally wrong about the way the DS it does ALL of its 3d rendering on an ARM9 clocked at 67 MHZ the N-spire is running an ARM9 clocked at 90 MHZ
from Wikipedia:
CPUs: Two ARM processors, an ARM946E-S main CPU and ARM7TDMI coprocessor at clock speeds of 67 MHz and 33 MHz respectively. The ARM946E-S CPU processes game play mechanisms and video rendering while the ARM7TDMI processes sound output, Wi-Fi support and additionally, when in Game Boy Advance mode, processes what the other processor used to do.
The DS has no vector coprocessor to speak of sorry to disappoint its just got an efficient engine.
the DS and n-spire use 2 different breeds of the ARM9 the N-spire using the highest end that has special instructions for JAVA optimization and the DS uses the second to highest end that may have more cache. I'm almost positive this can be done.
as a note:I mentioned the ray caster because it showed that such things could be done. To do portal one would of course need to optimize the hell out of the current ray caster or write a rasterization rendering engine
I quote Wikipedia:
The system's 3D hardware performs transform and lighting, texture-coordinate transformation, texture mapping, alpha blending, cel shading, and z-buffering
The DS definitely has 3D hardware. Good 3D graphics on the Nspire would really be pushing it. If calc84 could only get 70 FPS on an untextured, unsorted trivial scene, I doubt we can get an acceptable framerate with real scenes.
-
Keep in mind that some Calc84maniac stuff had an extreme amount of polygons, though. If he decreased the amount to stuff like on the Sega Saturn or PS1 and used scaled sprites for objects and characters/enemies (like many Nintendo 64 games), he might have chances to get a decent frame rate
-
you still have to render an entire scene that may consist of upwords of a few 100 polys (those 10 and 20 poly objects add up fast)
but with good real time rendering techniques you should never have to re-render the entire screen at once but then the question becomes memory because you might need to pre-render frames (source defaults to 8 I say that max for calc)
-
True, altough in some cases, certain maps could be kept simple or we could limit the amount of polygons drawn on the screen (the closest ones first). Also, in computer 3D games, textures drawn further are usually at lower quality (or absent). There are some stuff that could be done to help on framerate. That said, if it's still too slow, then I guess we may have to stick to the plain gray walls
-
Also if it's a team project, I think the source/files should be put somewhere all members can access, and backed up elsewhere in case a member went nuts or stole everything. I say this because in the 9 years I've been doing calc stuff (almost), I saw many team projects die because one member vanished completly, taking his portion of the code (or files) with him and the team member and his work was irreplaceable. Also each team members needs to agree on the project goals. Else it ends up in an endless debate. This is why nowadays you barely see any team project anymore in the TI community.
Hm... does that mean that the Hnefatafl game was the first team project in a long time to make a release? =P
Honestly, I'd love to see more team projects and be a part of them and I'm sure we could work things out between the members here. Several of us have been around for a LONG time and aren't planning on disappearing anytime soon. =)
-
Well Hnefatafl wasn't finished yet :P so that doesn't count as much, but yeah it had a release. I really meant massive projects, though, such as a big RPG, a calc OS or a programming language.
-
Well, a version of it was finished. =P
The game can be played without the AI just fine.
But yeah, I guess that means that Escheron will be the first huge team project done in a long time. Regardless, I still say that we should definitely start a new team project with an even bigger team than just 2 people. I'm kinda tired of doing everything alone. It was great being able to rely on someone for part of the work. ^^
-
Yeah true, for some people and some project it is better that the person gets help or that people work together
-
Aren't there sites now too that can help with storing everything in one place for people to access?
-
Yeah they're called SVN repositories and stuff like that. Google Code is an example, but now there are plenty of others. I am sure it is possible to create one here, but I do not know how it works.
-
Ah ok.
-
If we had an Nspire group project, it should be something along the lines of a standardized graphics/IO/math library.
This should be followed by a BASIC-like language, either interpreted, compiled, or compiled into C source.
We need to get the basic framework for development in place before thinking about coding new games.
-
Btw, how good is the Nspire C compiler? Does it produce compiled code that can be as good as ASM code written by an expert ASM programmer or does it produces much slower code? If the later is the case, it might be a good idea that somebody writes some 3D routines in ASM that can be used by C programmers in their programs.
-
Its just gcc, so I believe it produces slower code, but much slower.
-
/me wonders
with the floorcasting engine, although maybe it would be hard to make the camera look up/down and handle horizontal portals going in vertical ones or vice-versa, I wonder if, even if the graphic quality is decreased a bit, such project could be taken on now that there are some more Nspire coders and some other people here interested in C? I think looking through portals would be out of the question, though, and the game screen size would probably not be full screen (more like Gemini or Star Fox 84+)
-
Hmmmm im thinking that if it were to be done on the nSpire, raycasting would not be the engine to use, since its so hard (nigh impossible) to look down and up in large amounts. It would have to be something like CastleStorm maybe, since thats a relatively fast engine and it is still a tilemap based system so sorting is fine
-
I wonder if such engine could actually be used? My concern is textures, though. I fear if the C compiler isn't too good, it may require assembly for the 3D engine and in both cases, I wonder if textures would be fast enough at such large resolution.
-
I wonder if textures would even be a good idea with the screen blurriness. One thing about portal is that the player moves really fast some times x.x Either way, i wonder how portals would be handled? Like the mechanism for looking through them if possible.. hmmm...
-
Yeah for the blurriness frame rate would need to be reduced in the first place x.x