### Author Topic: Bug Reports  (Read 262626 times)

0 Members and 1 Guest are viewing this topic.

#### TIfanx1999

• ಠ_ಠ ( ͡° ͜ʖ ͡°)
• CoT Emeritus
• LV13 Extreme Addict (Next: 9001)
• Posts: 6173
• Rating: +191/-9
##### Re: Bug Reports
« Reply #1290 on: May 28, 2011, 10:37:35 am »
I'm sure he will after the bugs are noted and he has some free time. I wouldn't worry about it.

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1291 on: May 28, 2011, 10:47:20 am »
Here is the list of bugs I have discovered in Axe 0.5.3:

• 16-bit/16-bit division is broken and will always return zero! (See this post) Very bad!
• Except for bitwise operations, every mathematical auto optimization that results in no compiled code crashes when compiling! Also very bad!
• [Pre-existing] flipH() can produce a garbage sprite; see this post
• [Pre-existing] The //0 optimization (and the result of //(0) for that matter) is not mathematically correct due to being a signed operation
• [Pre-existing] The ^65535 optimization is not mathematically correct

Also, this isn't a bug, but could you add arbitrary buffer support to DispGraphrr? I put the buffer loading at the very start of the routine and added the push hl / pop hl specifically for this awesome purpose.

EDIT:
Quote
Commands.htm still says that DispGraphr and DispGraphrr will not work at 15MHz.
I'll fix that.
By the next version perhaps?
« Last Edit: May 28, 2011, 12:32:10 pm by Runer112 »

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
• I wish real life had a "Save" and "Load" button...
##### Re: Bug Reports
« Reply #1292 on: May 28, 2011, 03:05:07 pm »
Oops, I've fixed all of those now.  Although how can you say that //0 is incorrect?  It's undefined, it can be any number I want   On that subject though, the entire signed division routine rounds the wrong way and is inconsistent with the auto optimizations, that is, A//256 can return a slightly different value than A//(256), but I don't know how to fix that without bloating the code and its hardly noticeable.

I guess these bugs mean that 1.0.0 has to come out sooner than I though...
___Axe_Parser___
Today the calculator, tomorrow the world!

#### Freyaday

• The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
• LV10 31337 u53r (Next: 2000)
• Posts: 1970
• Rating: +128/-15
• I put on my robe and pixel hat...
##### Re: Bug Reports
« Reply #1293 on: May 28, 2011, 05:56:25 pm »
I still have 0.5.2, and
pxl-command->buffer does not work
Copy(PTR,L6,SIZE) does not work
Btw, is pxl-test()->buffer supposed to work or not?
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names

I'm a performer at heart; I stole it last week.
My Artwork!

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1294 on: May 28, 2011, 06:37:34 pm »
The pixel commands were never updated to support referencing any buffer, so it's not a big surprise that Pxl-Command()→Buffer doesn't work. Although looking at the routine, it definitely could work. I guess Quigibo just hasn't gotten around to adding it yet.

Copy() on the other hand has been around for a long time and has always worked. I'm guessing that it is actually working when you're using it, it's just not working how you are trying to make it work. If you could post a snippet of code showing how you're trying to use it, someone might be able to help you debug it.
« Last Edit: May 28, 2011, 06:38:25 pm by Runer112 »

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
• I wish real life had a "Save" and "Load" button...
##### Re: Bug Reports
« Reply #1295 on: May 28, 2011, 07:22:28 pm »
The main thing I'm concerned about with new pixel buffer commands is what I'm supposed to do about pxl-Test() which is half the reason you would use the command in the first place.  It looks too funky to have pxl-Test(X,Y)->P->A mean reading a pixel on buffer P into value A.  I guess I could have an optional 3rd argument instead so it looks like pxl-Test(X,Y,P)->A but this is inconsistent with the sprite drawing to buffers.  I would like consistency so I would rather change Pt-On(X,Y,S)->P into Pt-On(X,Y,S,P) as well if I did that, but that involves a compatibility issue.  I guess this is something to resolve before 1.0.0 because I don't want to make changes like this after.  Unless anyone is really against the change, I will probably change to the new syntax.  I never really liked the original storing syntax anyway, its not really any more intuitive than an extra argument, I don't remember why I did that in the first place.
« Last Edit: May 28, 2011, 07:24:07 pm by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

#### Freyaday

• The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
• LV10 31337 u53r (Next: 2000)
• Posts: 1970
• Rating: +128/-15
• I put on my robe and pixel hat...
##### Re: Bug Reports
« Reply #1296 on: May 28, 2011, 07:25:24 pm »
Zeroes(->I
.code defining W as mod 64
Pxl-On(W,0)->I
ClrDraw
Copy(I,L6,8)
DispGraph
.blank screen
ClrDrawr
Copy(I,L3,8)
L3->DispGraph
.Line from (0,0) to (63,0)
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names

I'm a performer at heart; I stole it last week.
My Artwork!

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1297 on: May 28, 2011, 07:28:01 pm »
I personally like the argument syntax as well. I think DispGraph(L3) looks better than L3→DispGraph, too. This would also make DispGraph(L6,L1)rr a possibility. *hint hint*

EDIT: And in response to Freyaday, since Pxl-Command()→Buffer isn't supported, Pxl-On(W,0)→I not only doesn't operate on the bytes pointed to by I, but it stores a value into I, overwriting the value you want it to hold. That's probably why you're not seeing what you want from the copying.
« Last Edit: May 28, 2011, 07:35:38 pm by Runer112 »

#### Freyaday

• The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
• LV10 31337 u53r (Next: 2000)
• Posts: 1970
• Rating: +128/-15
• I put on my robe and pixel hat...
##### Re: Bug Reports
« Reply #1298 on: May 28, 2011, 07:49:14 pm »
Ok.
* Freyaday goes to request a feature
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names

I'm a performer at heart; I stole it last week.
My Artwork!

#### ztrumpet

• The Rarely Active One
• CoT Emeritus
• LV13 Extreme Addict (Next: 9001)
• Posts: 5712
• Rating: +364/-4
• If you see this, send me a PM. Just for fun.
##### Re: Bug Reports
« Reply #1299 on: May 28, 2011, 09:43:43 pm »
I personally like the argument syntax as well. I think DispGraph(L3) looks better than L3→DispGraph, too. This would also make DispGraph(L6,L1)rr a possibility. *hint hint*
That sounds awesome, and I second the DispGraph(L6,L1)rr idea.

Quigibo, why don't you release a 0.5.4 or a 0.6.0 version with all of the current bugs fixed instead of pressuring yourself to have it all fixed by 1.0.0.
Edit:  Never mind:
I re-uploaded a fixed version so you won't have to wait until 1.0.0
« Last Edit: May 28, 2011, 09:44:33 pm by ztrumpet »
If I'm wrong, please correct me!
Unfinished Projects:
 Elmgon 14% Basic Movement Demo Homescreen Game Pack 80% Basic Latest Release Cube Droid Saves the Galaxy 65% Axe Demo Detonate 70% Axe
Completed Projects:
Exodus | Midnight |Drifter | Axe Snake | Jump! | Factory Theta | Spider | Plot Drop | Papi Jump | Numb3rs | Nibbler | Boost | Duel Tile Map Editor | Homescreen Map Editor | Key Group Check | Oasis

#### Munchor

• LV13 Extreme Addict (Next: 9001)
• Posts: 6199
• Rating: +295/-121
• Code Recycler
##### Re: Bug Reports
« Reply #1300 on: June 01, 2011, 06:02:05 pm »
Quigibo, in the AXEPONG.8XP game, the ball sometimes goes through the screen, perhaps because it has a velocity >256? Not really an Axe bug, but it's worth mentioning.

#### Darl181

• «Yo buddy, you still alive?»
• CoT Emeritus
• LV12 Extreme Poster (Next: 5000)
• Posts: 3408
• Rating: +305/-13
• VGhlIEdhbWU=
##### Re: Bug Reports
« Reply #1301 on: June 03, 2011, 07:35:36 pm »
Code: (working) [Select]
ClrDrawFor(A,0,767){A+L6} and (255)→{A+L6}EndMakes a solid black screen.  Works fine. However,
Code: (not working) [Select]
ClrDrawFor(A,0,767){A+L6} and ([FF])→{A+L6}End...makes a bunch of vertical bars, when it looks like it should do the same thing.

I'm not sure if this is a bug or if there's something different about hex chars...

EDIT: nvm, need to use EFF instead of brackets
« Last Edit: June 03, 2011, 07:37:27 pm by Darl181 »
Vy'o'us pleorsdti thl'e gjaemue

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1302 on: June 05, 2011, 09:37:03 pm »
I discovered this bug a while ago but forgot about it! Good thing I rediscovered it. If you put a comment on a data line, like so:

[0123456789ABCDEF] .The mage

The parser thinks the comment is an operand and produces code to load the data pointer into hl.

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
• I wish real life had a "Save" and "Load" button...
##### Re: Bug Reports
« Reply #1303 on: June 05, 2011, 10:17:56 pm »
Technically, that's an illegal use of a comment.  They're only supposed to start a line and not be put inline with other commands.  I don't check for that though because some people like to abuse it.  I guess I should either check or fix this.  There are other places that would have this problem too that I can think of.
___Axe_Parser___
Today the calculator, tomorrow the world!

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1304 on: June 05, 2011, 10:29:59 pm »
Ah. They work fine inline with just about everything else though.

Another bug that has probably been mentioned a bunch of times: drawing sprites to an arbitrary buffer reverses the X and Y coordinates. You pop them in the wrong order!