That ball challenge was such a pain until we figured out the secret

So easy

The technology is very real, and this company isn't the only one experimenting with it. The only reason the videos this company is releasing make it seem unreal is because they never state the downsides of their rendering engine. To name a few:

• Models built with voxels instead of polygons are incredibly large. If everything you saw in that video had the data density that they claimed, it would probably take up many terabytes, if not petabytes, of storage.
• Following from the first point, they probably get around this by using repeated structures, and lots of them. If you look at the wide, sweeping views, you'll see what I mean. The world looks like a big tilemap. I think the wilderness of a game like Oblivion looks much more realistic and is more immersive than this, and I wouldn't be surprised if Oblivion's landscape takes up a fraction of the storage space as well.
• Repeated structures cannot have individual entities be easily rotated, scaled, or otherwise modified, so they'll all look exactly alike. Which largely explains why the tilemapped landscape looks as bland as could possibly be.
• Do you see any animated entities? I do not, and this seems like a big flaw. Animating polygons is easy and just consists of moving a few hundred points along paths. But animating a few million points along paths? This is something that the rendering engine, no matter how powerful, can assist with.

This is a very interesting technology and I cannot question that it produces astounding graphics. But in its current state, it has a few large problems that haven't been solved, so I don't think it's ready for use in real products yet. My hat goes off to the first company to make an immserive landscape like that of Oblivion (my favorite game ever if you haven't guessed yet) using voxels that contains less than 25GB or so of data.

Technically, yes, it should be preceded with an octothorpe. The question is do we want to make a new token for #End, which probably wouldn't be as obvious to find as End and wouldn't make as much sense without token replacements.

That does work Quigibo, but it's unnecessarily slow and bloated if the only logic they require is AND.


Also, in response to this:

I'd like to have a debug macro (#Debug / #Release) and #Debug(code) would mean the code is only executed in debug mode, or something like this.

I've always wanted a compiler feature like this, but what would be infinitely more useful is #If. It could handle debug stuff and much more, like easily changeable compiling options. For instance, my old raycasting project had to have like 8 different copies of the source for slight rendering variations. #If would allow me to combine them all into one and make working on such projects much more manageable.

Well that's a whole other problem entirely. Axe 1.X seems to have problems identifying invalid tokens and throwing errors upon reaching them. As an extension of this problem, if you use an invalid token that Axe does recognize as invalid but you have included an Axiom in your program, it takes Axe a good few seconds upon reaching the invalid token to finally throw an error.

Someone asked for subtring and instring functions like those in TI-BASIC. So I made an Axe library with those two routines! Here's a quick summary of each one:

• SUB: Creates and returns a pointer to a substring of another string.
  
  • r1 = String
  • r2 = Start (1-indexed)
  • r3 = Length (1-255)
  • Notes: The 256-byte section of memory starting at $8000 is used as the substring buffer.
  • Example: SUB("HELLO WORLD!",7,6) would return a pointer to "WORLD!".
  
  
• INS: Returns the 1-indexed position of one string in another, or 0 if not found.
  
  • r1 = String
  • r2 = Search string
  • [Optional] r3 = Start (1-indexed)
  • Notes: The optional starting position in the string being searched should not exceed the length of the string.
  • Example: INS("HELLO WORLD!","A") would return 0.
  • Example: INS("HELLO WORLD!","WORLD") would return 7.
  • Example: INS("HELLO WORLD!","L",5) would return 10.

---

The Axe library is attached below. To use it in your program, simply send this to your calculator and include "prgmSTRLIB" in your program. I tested it a bit and think it works perfectly, but if not, please inform me!

The app version might need to disable interrupts, but why would the program version need to? Both Axe's and the OS's interrupt handlers back up the page in the $4000-$7FFF bank and restore it upon returning.

Quigibo, you read my mind. I was about to make a post with code for commands that deal with archived variables to work with variables in RAM too, but you added that in Axe 1.0.2 before I could finish! However, I'll make a post anyways because my p_GetArc routine is smaller. I also have a few other things.

---

p_GetArc: 7 bytes smaller.

Code: (Old code: 76 bytes) [Select] p_GetArc: .db __GetArcEnd-1-$ push de MOV9TOOP1() B_CALL(_ChkFindSym) jr c,__GetArcFail dec b inc b jr z,__GetArcRam B_CALL(_IsFixedName) ld hl,9 jr z,__GetArcName __GetArcStatic: ld l,12 and %00011111 jr z,__GetArcDone cp l jr z,__GetArcDone ld l,14 jr __GetArcDone __GetArcName: add hl,de bit 7,h jr z,$+7 res 7,h set 6,h inc b B_CALL(_LoadDEIndPaged) ld d,0 inc e inc e __GetArcDone: add hl,de ex de,hl __GetArcStore: pop hl ld (hl),e inc hl ld (hl),d inc hl ld (hl),b ex de,hl ret __GetArcRam: and %00011111 jr z,__GetArcStore cp CplxObj jr z,__GetArcStore inc de inc de jr __GetArcStore __GetArcFail: ld hl,0 pop de ret __GetArcEnd:

Code: (New code: 69 bytes) [Select] p_GetArc: .db __GetArcEnd-1-$ push de MOV9TOOP1() B_CALL(_ChkFindSym) jr c,__GetArcFail dec b inc b jr z,__GetArcRam B_CALL(_IsFixedName) ld hl,9 jr z,__GetArcName ld l,12 __GetArcChkFloat: and %00011111 jr z,__GetArcDone cp CplxObj jr z,__GetArcDone inc l inc l jr __GetArcDone __GetArcName: add hl,de bit 7,h jr z,$+7 res 7,h set 6,h inc b B_CALL(_LoadDEIndPaged) ld d,0 inc e inc e __GetArcDone: add hl,de ex de,hl pop hl ld (hl),e inc hl ld (hl),d inc hl ld (hl),b ex de,hl ret __GetArcRam: ld h,b ld l,b jr __GetArcChkFloat __GetArcFail: ld hl,0 pop de ret __GetArcEnd:

---

p_ReadArc: Bumping an old request for larger but drastically faster archive reading routines. The routines would need to modified slightly to allow for reading from RAM as well, but that should be no problem. I would understand if you didn't want to add the app version, but the program version is immensely better in my opinion.

And on the topic of stuff that involves port 6, I think it would be nice if the archive byte reading routine avoided using a B_CALL for a massive speed boost, especially for code compiled as programs:

p_ReadArc: 18 bytes (2x) larger, but ~1400 cycles (!!!10x!!!) faster

Code: (36 bytes, ~142 cycles) [Select]

p_ReadArc:
.db __ReadArcEnd-1-$
ld c,a
in a,(6)
ld b,a
ld a,h
set 6,h
res 7,h
rlca
rlca
dec a
and %00000011
add a,c
out (6),a
ld c,(hl)
inc hl
bit 7,h
jr z,__ReadArcNoBoundary
set 6,h
res 7,h
inc a
out (6),a
__ReadArcNoBoundary:
ld l,(hl)
ld h,c
ld a,b
out (6),a
ret
__ReadArcEnd:

p_ReadArcApp: 36 bytes (3x) larger, but ~1050 cycles (4x) faster

Code: (54 bytes, ~396 cycles) [Select]

p_ReadArcApp:
.db __ReadArcAppEnd-1-$
push hl
ld hl,$0000
ld de,ramCode
ld bc,__ReadArcAppRamCodeEnd-__ReadArcAppRamCode
ldir
pop hl
ld e,a
ld c,6
in b,(c)
ld a,h
set 6,h
res 7,h
rlca
rlca
dec a
and %00000011
add a,e
call ramCode
ld e,d
inc hl
bit 7,h
jr z,__ReadArcAppNoBoundary
set 6,h
res 7,h
inc a
__ReadArcAppNoBoundary:
call ramCode
ex de,hl
ret
__ReadArcAppEnd:
.db rp_Ans,__ReadArcAppEnd-p_ReadArcApp-3

__ReadArcAppRamCode:
out (6),a
ld d,(hl)
out (c),b
ret
__ReadArcAppRamCodeEnd:


---

p_CopyArc: Modified to allow for sources in RAM.

Code: (Old code: 22 bytes) [Select] p_CopyArc: .db __CopyArcEnd-1-$ pop ix pop de ex (sp),hl ld b,a ld a,h rlca rlca dec a and %00000011 add a,b set 6,h res 7,h pop bc B_CALL(_FlashToRAM) jp (ix) __CopyArcEnd:

Code: (New code: 28 bytes) [Select] p_CopyArc: .db __CopyArcEnd-1-$ ex (sp),hl pop bc pop de ex (sp),hl or a jr z,__CopyArcRam push bc ld b,a ld a,h rlca rlca dec a and %00000011 add a,b set 6,h res 7,h pop bc B_CALL(_FlashToRAM) ret __CopyArcRam: ldir ret __CopyArcEnd:

---

Also, I'm not sure why I just realized this now, but why don't the 8-bit logic operations on variables just load the variable into a instead of de to save 2 bytes?