#126809 - Rajveer - Thu Apr 26, 2007 11:44 pm
Hi guys. At the moment I'm storing 3D level data using a data structure in a C file with information such as polygons, normals, texture coordinates. I'm still having the compilation time problems I was having before except that information is stored in a C file now http://forum.gbadev.org/viewtopic.php?t=12480&highlight=compiling+array
The main problem now however is that when storing around 150 polygons, the game freezes at the beginning and doesn't load. I'm not sure if I'm using memory properly and I think I'm overloading whichever section of memory I'm using, so what would you guys suggest? Which area of memory should I store the array, considering that some of the data needs to change on the fly?
#126818 - sajiimori - Fri Apr 27, 2007 1:20 am
I don't know what the typical homebrew setup does, but check your linkscript to make sure data is going in main RAM by default, and not DTCM.
In the long run, you'll want to store that data in a filesystem of some sort. Otherwise you'd have to carry all your levels in RAM all the time.
#126822 - Rajveer - Fri Apr 27, 2007 2:18 am
Cheers for the reply. At the moment I'm using the PALib standard makefile, so are you suggesting that I start making my own and sort out memory locations during linkage on my own? Aren't memory location setup in the actual programming or am I wrong?
Also, later I will plan on storing data in a filesystem, but the selected level data will still be loaded into RAM with arrays and structs right?
#126832 - tepples - Fri Apr 27, 2007 4:04 am
First try making the geometry structs const. That should force them into EWRAM (4 MB) instead of DTCM (much smaller), even on makefiles created several devkitARM revisions ago before the standard link script put .data into EWRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126894 - Rajveer - Fri Apr 27, 2007 10:49 pm
One problem with declaring the geometry structs as const will be that I won't be able to modify some data. Each polygon has an associated "timestamp" variable which is set if the polygon has already been tested in a certain frame, to avoid unnecessary processing. Any ways of getting around this?
#126906 - HyperHacker - Sat Apr 28, 2007 12:19 am
So right now your level data is an array defined in a source file? If it's local and not static, you're almost certainly going to blow the stack with that much information. Otherwise, I'd check if any code that runs before referencing the array. (Try putting something that will produce some manner of output as the first instruction of main() on each CPU - draw a pixel on ARM9, blink the power LED on ARM7 is a good bet, since they're fairly simple.) If it doesn't, then you know the array itself is the problem.
Also I hope your level data isn't just one big mesh? The logic will be a lot easier and faster if you divide things into objects, each of which point to an array of polygons. The objects have their world coordinates, speed, size etc and the polygons have coordinates where 0,0,0 = center of the object. This way, for example, moving a character or scaling things up and down becomes a simple matter of changing SomeObject.Position or SomeObject.Size, and if you have two of the same character, they can share polygon data instead of duplicating it. I realize this is probably blatantly obvious, but your comment about per-polygon timestamps made it sound like you weren't using this method.
_________________
I'm a PSP hacker now, but I still <3 DS.
#126921 - sajiimori - Sat Apr 28, 2007 1:27 am
Store the timestamps in a separate array. Your polys should all have some numeric ID, usually just their index in the array of all polys. The timestamp array would use the same indices.
Still, if non-const data is going in DTCM by default, then your linkscript is weird and it should be modified. It's true that the memory layout is determined programmatically, but crt0.s handles all that -- it follows the instructions left by the linkscript.
You normally don't modify crt0.s to change memory layout; you change the linkscript.
And again, using a filesystem is highly preferable to statically linking all of it.
#126932 - Rajveer - Sat Apr 28, 2007 3:12 am
@HyperHacker: Good idea. I recompiled with smaller and larger arrays and it's definately causing the problem and must be blowing the DTCM. At the moment the level data is one big mesh, but that's because that's the way it works best for my game, level data is just a track with a few polygons here and there for buildings and such.
@sajiimori: Ah that makes sense, creating a timestamp array at loading time. I'm using the PALib makefile and whatever link script that works, I've never created my own but I guess it's time for me to look into it.
1) So should I look into how to use libfat and store all my level data on the card?
2) When loading data, would I stream the data stored in a level file into the data structure I'm using? I've never done anything like streaming data from a file.
3) And how would I ensure that the streamed data would go into main memory and not DTCM, I'm assuming it's not done through the linker as the linker just has rules for data already initialised whereas I'd be reading in data at run-time?
4) One last question, is there a method to read compressed files if I were to store all my level data in a zipped file or something?
#126933 - tepples - Sat Apr 28, 2007 3:39 am
| Rajveer wrote: |
| 1) So should I look into how to use libfat and store all my level data on the card? |
Yes.
| Quote: |
| 2) When loading data, would I stream the data stored in a level file into the data structure I'm using? I've never done anything like streaming data from a file. |
malloc() always allocates from main memory.
| Quote: |
| 4) One last question, is there a method to read compressed files if I were to store all my level data in a zipped file or something? |
If you include a zip library, then yes, you can read zip files using libfat.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126934 - Rajveer - Sat Apr 28, 2007 3:41 am
Aha! Great, thanks for answering my questions tepples!
#127117 - Rajveer - Mon Apr 30, 2007 3:44 am
Ok so just for testing purposes and so I can continue my project without libfat (until I get everything sorted which I need complete) I decided to scrap using the PALib makefile and am using the standard one with libnds. The same problem occurs without declaring the array as a const, except that the program runs before the level is loaded and freezes upon array initialisation. Just wondering, the link script is setup within the makefile right, so why does the link script still not put the data into EWRAM?
#127121 - tepples - Mon Apr 30, 2007 4:03 am
Do this at a command prompt:
| Code: |
set PATH=C:\devkitPro\devkitARM\bin;%PATH%
arm-eabi-nm -n arm9.elf > map.txt |
and paste the contents of map.txt here.
Normally, addresses from 0x02000000 to 0x023FFFFF represent EWRAM (main memory). Addresses outside this range are smaller chunks such as DTCM or shared IWRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#127152 - Rajveer - Mon Apr 30, 2007 1:03 pm
Ahh great, thanks tepples I never knew you could do that! I've checked and it says that EWRAM starts at 0x02068720 and the array which I want (Level1Poly) is within the range with the correct size allocated for it's size. Must be another problem now...also it still works on iDeas but not on hardware...
| Code: |
w __deregister_frame_info
w __register_frame_info
w _Jv_RegisterClasses
00080000 A _stack
01000000 A __itcm_start
01000000 T irqTable
010000c8 T IntrMain
010000fc t findIRQ
01000118 t no_handler
01000128 t jump_intr
0100013c t got_handler
0100015c t IntrRet
01000190 A __itcm_end
02000000 T __text_start
02000000 T _start
02000158 t ILoop
0200015c t ClearMem
02000170 t ClrLoop
02000180 t CopyMemCheck
02000184 t CopyMem
02000194 t CIDLoop
02000220 T _init
02000230 t __do_global_dtors_aux
0200025c t frame_dummy
020002a0 T Draw3DS
02004e20 T traverseOctree
02004f58 T triAABBTest
0200507c T findEmptyLinkedListNode
020050a4 T rayPolyTest
020055a4 T testAABB_Octree
020057a0 T applyGrav
02005990 T addThrustVectorToFinalVector
02005bb4 T applyFrictionToFinalVector
02005c40 T applyGroundReactionVector
02005f6c T checkCollision
0200619c T applyStrafeForce
020063f0 T applySideThrustForce
020066bc T vBlank
020066f4 T arccomp
02006724 T lapManager
020067ac T arccos
020067e0 T DrawSkybox
02006b68 T DrawLevel1
02006cf0 T DrawGLScene
02007364 T LoadGLTextures
020075fc T menuShipSelect
02007c64 T clearPolyList
02007c94 T addLinkedListNode
02007ccc T addNode
0200808c T buildOctree
02008260 T rotateYAxis
020088e8 T moveComp
02008d94 T getRotationAxis
020098e0 T rotateToWaypoint
0200a4e0 T playerManager
0200a698 T rotateXAxis
0200ad1c T checkShipGroundCollision
0200b454 T checkPlayers
0200b650 T main
02014d48 T keysHeld
02014d54 T keysDown
02014d68 T scanKeys
02014dfc T keysDownRepeat
02014e0c T keysSetRepeat
02014e30 T keysUp
02014e48 T vramSetMainBanks
02014e8c T vramRestorMainBanks
02014e98 T vramRestoreMainBanks
02014ea4 T vramSetBankA
02014eb8 T vramSetBankB
02014ecc T vramSetBankC
02014ee0 T vramSetBankD
02014ef4 T vramSetBankE
02014f08 T vramSetBankF
02014f1c T vramSetBankG
02014f30 T vramSetBankH
02014f44 T vramSetBankI
02014f58 T glEnable
02014f78 T glDisable
02014f94 T glLoadMatrix4x4
02014fdc T glLoadMatrix4x3
02015014 T glMultMatrix4x4
0201505c T glMultMatrix4x3
02015094 T glMultMatrix3x3
020150c0 T glRotateZi
020150fc T glRotateYi
0201513c T glRotateXi
02015178 T glRotateX
020151ac T glRotateY
020151dc T glRotateZ
0201520c T glVertex3f
02015260 T glColor3f
020152b8 T glScalef
02015300 T glTranslatef
02015348 T glNormal3f
0201544c T glOrthof32
02015600 T glOrtho
02015684 T glFrustumf32
02015848 T glFrustum
020158cc T gluPerspectivef32
02015958 T gluPerspective
020159d8 T gluPickMatrix
02015a6c T glMaterialf
02015aec T glResetMatrixStack
02015b24 T glSetOutlineColor
02015b34 T glSetToonTable
02015b4c T glSetToonTableRange
02015b68 T glResetTextures
02015b94 T glGenTextures
02015bd0 T glBindTexture
02015bf8 T glColorTable
02015c10 T glTexParameter
02015c3c T glGetTexturePointer
02015c4c T glGetTexParameter
02015c60 T alignVal
02015c70 T getNextPaletteSlot
02015cb8 T vramGetBank
02015d70 T vramIsTextureBank
02015dd4 T getNextTextureSlot
02015e28 T glGetInt
02015e88 T intof32
02015e8c T floatof32
02015ea4 T intot16
02015eac T floatot16
02015ec8 T intov16
02015ed0 T floatov16
02015eec T intov10
02015ef4 T floatov10
02015f10 T glSetAlpha
02015f20 T glAlphaFunc
02015f30 T glCutoffDepth
02015f3c T glTexLoadPal
02015f70 T gluTexLoadPal
02015f94 T glTexImage2D
02016064 T glTexCoord2f32
020160e0 T glTexCoord2f
02016178 T glReset
020161d4 T glGetFixed
0201629c T gluLookAtf32
02016754 T gluLookAt
02016800 T glRotatef32i
02016aec T glRotatef32
02016b24 T glRotatef
02016b78 T irqDummy
02016b7c T irqSet
02016be4 T irqInit
02016c30 T irqClear
02016cb0 T irqInitHandler
02016ce0 T irqEnable
02016d30 T irqDisable
02016d80 T swiSoftReset
02016d84 T swiDelay
02016d88 T swiIntrWait
02016d8c T swiWaitForVBlank
02016d90 T swiSleep
02016d94 T swiChangeSoundBias
02016d98 T swiDivide
02016d9c T swiRemainder
02016da2 T swiDivMod
02016dae T swiCopy
02016db2 T swiFastCopy
02016db6 T swiSqrt
02016dba T swiCRC16
02016dbe T swiIsDebugger
02016dc2 T swiUnpackBits
02016dc6 T swiDecompressLZSSWram
02016dca T swiDecompressLZSSVram
02016dce T swiDecompressHuffman
02016dd2 T swiDecompressRLEWram
02016dd6 T swiDecompressRLEVram
02016dda T swiWaitForIRQ
02016dde T swiDecodeDelta8
02016de2 T swiDecodeDelta16
02016de6 T swiSetHaltCR
02016df0 T __aeabi_idiv
02016df0 T __divsi3
02016e84 T __aeabi_idivmod
02016e94 T __aeabi_idiv0
02016e94 T __aeabi_ldiv0
02016e94 T __div0
02016e98 T _call_via_r0
02016e9c T _call_via_r1
02016ea0 T _call_via_r2
02016ea4 T _call_via_r3
02016ea8 T _call_via_r4
02016eac T _call_via_r5
02016eb0 T _call_via_r6
02016eb4 T _call_via_r7
02016eb8 T _call_via_r8
02016ebc T _call_via_r9
02016ec0 T _call_via_sl
02016ec4 T _call_via_fp
02016ec8 T _call_via_ip
02016ecc T _call_via_sp
02016ed0 T _call_via_lr
02016ed4 T __aeabi_drsub
02016edc T __aeabi_dsub
02016edc T __subdf3
02016ee0 T __adddf3
02016ee0 T __aeabi_dadd
020171f0 T __aeabi_ui2d
020171f0 T __floatunsidf
02017214 T __aeabi_i2d
02017214 T __floatsidf
0201723c T __aeabi_f2d
0201723c T __extendsfdf2
0201727c T __aeabi_ul2d
0201727c T __floatundidf
02017290 T __aeabi_l2d
02017290 T __floatdidf
020172f0 T __aeabi_dmul
020172f0 T __muldf3
02017580 T __aeabi_ddiv
02017580 T __divdf3
0201778c T __aeabi_d2iz
0201778c T __fixdfsi
020177e8 T __aeabi_d2f
020177e8 T __truncdfsf2
02017888 T __aeabi_frsub
02017890 T __aeabi_fsub
02017890 T __subsf3
02017894 T __addsf3
02017894 T __aeabi_fadd
02017a50 T __aeabi_ui2f
02017a50 T __floatunsisf
02017a58 T __aeabi_i2f
02017a58 T __floatsisf
02017a78 T __aeabi_ul2f
02017a78 T __floatundisf
02017a88 T __aeabi_l2f
02017a88 T __floatdisf
02017b34 T __aeabi_fmul
02017b34 T __mulsf3
02017ccc T __aeabi_fdiv
02017ccc T __divsf3
02017e2c T __gesf2
02017e2c T __gtsf2
02017e34 T __lesf2
02017e34 T __ltsf2
02017e3c T __cmpsf2
02017e3c T __eqsf2
02017e3c T __nesf2
02017e9c T __aeabi_cfrcmple
02017eac T __aeabi_cfcmpeq
02017eac T __aeabi_cfcmple
02017ec4 T __aeabi_fcmpeq
02017edc T __aeabi_fcmplt
02017ef4 T __aeabi_fcmple
02017f0c T __aeabi_fcmpge
02017f24 T __aeabi_fcmpgt
02017f3c T __aeabi_f2iz
02017f3c T __fixsfsi
02017f98 T __aeabi_f2uiz
02017f98 T __fixunssfsi
02017fec T __aeabi_lmul
02017fec T __muldi3
02018070 T bsearch
020180d0 T __libc_fini_array
02018100 T __libc_init_array
02018158 T _iprintf_r
02018174 T iprintf
02018198 T free
020181b0 T malloc
020181c8 T _malloc_r
02018714 T __malloc_lock
02018718 T __malloc_unlock
0201871c T _sbrk_r
02018748 t __sprint_r
02018768 T _vfiprintf_r
02019400 T vfiprintf
02019424 T _wcrtomb_r
02019458 T wcrtomb
0201947c T _wcsrtombs_r
02019558 T wcsrtombs
02019580 T _wctomb_r
02019848 T __swsetup
020198f8 T fflush
02019a04 t std
02019a3c T __sfp_lock_acquire
02019a40 T __sfp_lock_release
02019a44 T __sinit_lock_acquire
02019a48 T __sinit_lock_release
02019a4c T __sinit
02019aa8 t __fp_lock
02019aac t __fp_unlock
02019ab0 T __fp_unlock_all
02019acc T __fp_lock_all
02019ae8 T _cleanup_r
02019afc T _cleanup
02019b14 T __sfmoreglue
02019b4c T __sfp
02019bd0 T _malloc_trim_r
02019c74 T _free_r
02019e40 T __sfvwrite_r
0201a0fc T _fwalk_reent
0201a168 T _fwalk
0201a1d0 T __locale_charset
0201a1dc T _localeconv_r
0201a1e4 T localeconv
0201a1fc T _setlocale_r
0201a244 T setlocale
0201a260 T __smakebuf
0201a344 T memchr
0201a3f8 T memmove
0201a47c T memset
0201a4dc T _realloc_r
0201a8b0 T _wrapup_reent
0201a900 T cleanup_glue
0201a924 T _reclaim_reent
0201a9c8 T __sclose
0201a9e4 T __sseek
0201aa24 T __swrite
0201aa6c T __sread
0201aaa8 T strcmp
0201ab10 T strlen
0201ab60 T _write_r
0201ab90 T _close_r
0201abbc T _fclose_r
0201ac64 T fclose
0201ac80 T _fstat_r
0201acb0 T _lseek_r
0201ace0 T _read_r
0201ad10 T __aeabi_uidiv
0201ad10 T __udivsi3
0201ad8c T __aeabi_uidivmod
0201ad9c T _close
0201ade8 T _fstat
0201ae38 T isatty
0201ae3c T _lseek
0201ae74 T _read
0201aec8 T _sbrk
0201af2c T _write
0201af80 T setDefaultDevice
0201af94 T AddDevice
0201b00c T FindDevice
0201b074 T RemoveDevice
0201b0a0 T strncmp
0201b134 t ___call_via_r3_from_arm
0201b140 t ____aeabi_i2f_from_thumb
0201b144 T ____aeabi_i2f_change_to_arm
0201b148 t ____aeabi_fmul_from_thumb
0201b14c T ____aeabi_fmul_change_to_arm
0201b150 t ____aeabi_f2d_from_thumb
0201b154 T ____aeabi_f2d_change_to_arm
0201b158 t ____aeabi_dmul_from_thumb
0201b15c T ____aeabi_dmul_change_to_arm
0201b160 t ____aeabi_d2iz_from_thumb
0201b164 T ____aeabi_d2iz_change_to_arm
0201b168 t ____aeabi_f2iz_from_thumb
0201b16c T ____aeabi_f2iz_change_to_arm
0201b170 t ____aeabi_f2uiz_from_thumb
0201b174 T ____aeabi_f2uiz_change_to_arm
0201b178 t ____aeabi_fcmpge_from_thumb
0201b17c T ____aeabi_fcmpge_change_to_arm
0201b180 t ____aeabi_d2f_from_thumb
0201b184 T ____aeabi_d2f_change_to_arm
0201b188 t ____aeabi_fcmple_from_thumb
0201b18c T ____aeabi_fcmple_change_to_arm
0201b190 T _fini
0201b19c A __text_end
0201b19c R back_bin_size
0201b1a0 R back_bin
020231a0 R back_bin_end
020231a0 R bottom_bin_size
020231a4 R bottom_bin
0202b1a4 R bottom_bin_end
0202b1a4 R front_bin_size
0202b1a8 R front_bin
020331a8 R front_bin_end
020331a8 R left_bin_size
020331ac R left_bin
0203b1ac R left_bin_end
0203b1ac R right_bin_size
0203b1b0 R right_bin
020431b0 R right_bin_end
020431b0 R road2_bin_size
020431b4 R road2_bin
020433b4 R road2_bin_end
020433b4 R road3_bin_size
020433b8 R road3_bin
020473b8 R road3_bin_end
020473b8 R road3_pal_bin_size
020473bc R road3_pal_bin
020473fc R road3_pal_bin_end
020473fc R ship1texture_bin_size
02047400 R ship1texture_bin
0204b400 R ship1texture_bin_end
0204b400 R ship1texture_pal_bin_size
0204b404 R ship1texture_pal_bin
0204b604 R ship1texture_pal_bin_end
0204b604 R ship2texture_bin_size
0204b608 R ship2texture_bin
0204f608 R ship2texture_bin_end
0204f608 R ship2texture_pal_bin_size
0204f60c R ship2texture_pal_bin
0204f80c R ship2texture_pal_bin_end
0204f80c R shipselectmenu_bin_size
0204f810 R shipselectmenu_bin
0205f810 R shipselectmenu_bin_end
0205f810 R top_bin_size
0205f814 R top_bin
02067814 R COS_bin_size
02067814 R top_bin_end
02067818 R COS_bin
02067c18 R COS_bin_end
02067c5c R SIN_bin_size
02067c60 R SIN_bin
02068060 R SIN_bin_end
02068060 R TAN_bin_size
02068064 R TAN_bin
02068464 R TAN_bin_end
020685d0 r zeroes.3146
020685e0 r blanks.3145
020685f0 R _global_impure_ptr
020685f4 r lconv
02068624 r charset
02068628 R dotab_stdnull
02068710 A __exidx_end
02068710 A __exidx_start
02068710 t __frame_dummy_init_array_entry
02068710 A __init_array_start
02068710 A __preinit_array_end
02068710 A __preinit_array_start
02068714 t __do_global_dtors_aux_fini_array_entry
02068714 A __fini_array_start
02068714 A __init_array_end
02068718 r __EH_FRAME_BEGIN__
02068718 A __fini_array_end
02068718 r __FRAME_END__
0206871c d __JCR_END__
0206871c d __JCR_LIST__
02068720 A __data_start
02068720 D __dso_handle
02068720 A __ewram_start
02068724 D currentCamera
02068725 D drawSkyBoxSwitch
02068726 d delay
02068727 d repeat
02068728 d count
0206872c D nextBlock
02068730 D nameCount
02068734 d enable_bits
02068738 D __malloc_av_
02068b40 D __malloc_trim_threshold
02068b44 D __malloc_sbrk_base
02068b48 D _impure_ptr
02068b50 d impure_data
02068f60 D __mb_cur_max
02068f64 D __lc_ctype
02068f70 D devoptab_list
02068fb0 d defaultDevice
02068fb4 A __data_end
02068fb4 A __dtcm_lma
02068fb4 A __itcm_lma
02069144 A __appended_data
02069144 A __bss_lma
02069144 A __bss_start
02069144 A __bss_start__
02069144 b completed.2604
02069148 b object.2646
02069160 B ship_3ds
02069164 B numberOfCollisionTests
02069168 B maxNumberOfCollisionTests
0206916c B frameCounter
02069170 B loopCounter
02069174 B elapsedFrames
02069178 B frameold
0206917c b keys
0206917e b keysold
02069180 b keysrepeat
02069184 B activeTexture
02069188 B nextPBlock
0206918c b specular_emission.3038
02069190 b diffuse_ambient.3037
02069194 B __malloc_top_pad
02069198 B __malloc_max_sbrked_mem
0206919c B __malloc_max_total_mem
020691a0 B __malloc_current_mallinfo
020691c8 B __nlocale_changed
020691cc B __mlocale_changed
020691d0 B _PathLocale
020691d4 b heap_start.2452
020691d8 B fake_heap_end
020691dc B fake_heap_start
020691e0 B Level1Waypoint
02069690 B cameraup
0206969c B road3Palette
020696a0 B waypointLimit
020696a4 B polylimit
020696a8 B ship
020696b8 B timestamp
020696bc B player
02069a64 B levelLowLimit
02069a68 B collisionListHead
02069a6c B Level1Poly
0206d75c B texture
0206d774 B roadtextures
0206d77c B shipPalette
0206d784 B shiptextures
0206d78c B head
0206d790 B correctNode
0206d794 B LevelScale
0206d798 B camerapos
0206d7a4 B futureNode
0206d7a8 B shipselecttextures
0206d7b0 B waypointBoundary
0206d7b4 B cameralook
0206d7c0 B currentPolyListNode
0206d7c4 B textures
0206f7c4 B errno
0206f7c8 A __bss_end
0206f7c8 A __bss_end__
0206f7c8 A __end__
0206f7c8 A _end
023ff000 A __eheap_end
023ff000 A __ewram_end
0b000000 A __dtcm_end
0b000000 A __dtcm_start
0b000000 A __sbss_end
0b000000 A __sbss_start
0b000000 A __sbss_start__
0b003d00 A __sp_usr
0b003e00 A __sp_irq
0b003f00 A __sp_svc
0b003ff8 A __irq_flags
0b003ffc A __irq_vector
0b004000 A __dtcm_top
|
Thinking about it, the process for building the octree is a recursive one so could the memory which stores the current state of the program be overloaded? I doubt it but I have no idea...
#127187 - tepples - Mon Apr 30, 2007 7:13 pm
The ARM9 stack doesn't go in main memory; it goes in a smaller, faster memory. If you convert your octree code to use iteration and explicit stack management instead of recursion, you can put the stack into main memory.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#127231 - Rajveer - Tue May 01, 2007 1:13 am
Cool, I have deduced that it is definately the octree, I'll have to look into how to convert recursive functions into iterative ones, thanks for the advice. I'm not too sure what you mean by explicit state management, could you enlighten me?
#127244 - tepples - Tue May 01, 2007 4:27 am
When converting a non-tail-recursive function to iteration, sometimes you need to save data for future iterations, where the function would normally call itself. This means you need to push and pop things on a stack emulated in software. There are several ways to make a stack in main memory, such as an array list or a linked list.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#127451 - Rajveer - Wed May 02, 2007 4:41 pm
Aha. I've got the idea, I'll look into it after my exams. Thanks tepples!