Jump to content
IGNORED

2018 Contest Chat


Recommended Posts

I've heard there are at least two games in the works and possibilities of two more :)

 

So, potentially 8 entries? That's not bad at all! And I will say that the entries we've seen so far have all been great. I can't wait to see what else comes! :)

 

Great job, every one!

 

-dZ.

  • Like 1
Link to comment
Share on other sites

I was wondering if posting fake entries in order to reach the minimum number of entries would have been morally acceptable ?

 

Happy to hear that there will be no need of tricks to keep the competition active.

?

 

BTW, I 'am still convinced that DZ, you should have entered with a game yourself

Edited by artrag
Link to comment
Share on other sites

I was wondering if posting fake entries in order to reach the minimum number of entries would have been morally acceptable ?

 

Hehe. I recall last year we were concerned about the number of entries, and at the end we got a few "surprise projects." I hope for the same this year.

 

BTW, I 'am still convinced that DZ, you should have entered with a game yourself

Nah, I'm not good at IntyBASIC. That's not "Assembly programmer snobbery," really; I have enough trouble keeping up one language in my head, I don't wish to cram more stuff in there.

 

Slowness, procrastination, and short memory are my super-powers. :grin:

 

Besides, I am actively working on my game development framework for my own games. I doubt I'll ever get around to learn proper IntyBASIC.

 

That's not a slight to the language at all, it's very good and versatile, and obviously superbly capable for making great Intellivision games. :)

 

dZ.

Link to comment
Share on other sites

Hopefully I'll have a filler entry before the end of the competition too, but I want to add some more functionality & remove some of the bugs before posting it, in order for testers to concentrate on valuable feedback and not get stuck with details I already know will need to be fixed.

  • Like 1
Link to comment
Share on other sites

Nah, I'm not good at IntyBASIC. That's not "Assembly programmer snobbery," really; I have enough trouble keeping up one language in my head, I don't wish to cram more stuff in there.

 

Slowness, procrastination, and short memory are my super-powers. :grin:

 

Besides, I am actively working on my game development framework for my own games. I doubt I'll ever get around to learn proper IntyBASIC.

 

That's not a slight to the language at all, it's very good and versatile, and obviously superbly capable for making great Intellivision games. :)

 

dZ.

Dispatching a group of poorly trained monkeys at your location to help train you on Intybasic. :P

 

I'm only kidding. I'm like that way with batari Basic. It's really good at making games quickly, but doesn't give me the control over the display kernal and displaying 2 sprites, and few missile and/or ball is a bit limited for me. So I went ASM in that route so I have more control over the display kernal to have more objects on screen and more RAM to use for my games.

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

Hi guys, remember me?

 

Sorry I haven't been around much. I haven't even been around the video tech forums either where I've been for over a decade before. Work, life, etc, even a death in the family, have kept me away.

 

But I still tune in once in a while and stalk you folks. :-P And I still love IntyBASIC - it totally rocks. It's really amazing how it added so much to my life last contest. :-) Really, no joke!

 

Expect an entry from me too. Still have lots of bugs to clean out, but it should be a fun, fun game. Friends, and family members got a kick out of it.

  • Like 3
Link to comment
Share on other sites

Hi guys, remember me?

 

Sorry I haven't been around much. I haven't even been around the video tech forums either where I've been for over a decade before. Work, life, etc, even a death in the family, have kept me away.

 

But I still tune in once in a while and stalk you folks. :-P And I still love IntyBASIC - it totally rocks. It's really amazing how it added so much to my life last contest. :-) Really, no joke!

 

Expect an entry from me too. Still have lots of bugs to clean out, but it should be a fun, fun game. Friends, and family members got a kick out of it.

Welcome back! :) :thumbsup:

  • Like 1
Link to comment
Share on other sites

Hi guys, remember me?

 

Sorry I haven't been around much. I haven't even been around the video tech forums either where I've been for over a decade before. Work, life, etc, even a death in the family, have kept me away.

 

But I still tune in once in a while and stalk you folks. :-P And I still love IntyBASIC - it totally rocks. It's really amazing how it added so much to my life last contest. :-) Really, no joke!

 

Expect an entry from me too. Still have lots of bugs to clean out, but it should be a fun, fun game. Friends, and family members got a kick out of it.

 

Cool! Remember, you still have about three weeks to the end of the contest. Also, don't forget to submit your entry officially via e-mail, as per the contest instructions.

 

:thumbsup:

  • Like 1
Link to comment
Share on other sites

Thanks guys. Yes indeed, you can count on mine before the deadline. That's about 10 entries now expected? Great - we have a contest!

 

Shameless hint: To give an idea, think of it as "Deadly Dogs 2" or "Insane" (as a sequel to Berzerk and Frenzy), but those names would infringe on copyrights. However, I have a better name for it. :P Ha ha.

 

And yes, it's the same character, and yes, he has his bowling ball again... No, it's not a bowling game. It's just some punk being rude. That's all.

Link to comment
Share on other sites

A couple of years ago, I was considering a game about sumo bowling, where one would first wrestle your opponent out of the ring and throw him to knock down bowling pins. I never got further than a rough ASCII sketch. Perhaps that is just as good, though anyone willing to flesh (haha) it out is welcome to reuse my idea...

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

A couple of years ago, I was considering a game about sumo bowling, where one would first wrestle your opponent out of the ring and throw him to knock down bowling pins. I never got further than a rough ASCII sketch. Perhaps that is just as good, though anyone willing to flesh (haha) it out is welcome to reuse my idea...

 

Was just thinking... I had this concept, a while ago actually, of making a game that makes you pierce your eyelids and moon nuns. I thought I had the most "out there" idea ever. Until your post...

Link to comment
Share on other sites

Cheesus.. two days before the deadline and I'm starting to get gremlins from the compiler! Suddenly code belonging in a different procedure than I am executing, is running. I might shadow that function out and submit a less complete version than intended.

Link to comment
Share on other sites

Cheesus.. two days before the deadline and I'm starting to get gremlins from the compiler! Suddenly code belonging in a different procedure than I am executing, is running. I might shadow that function out and submit a less complete version than intended.

 

:o :O Post some code, maybe we can help!

Link to comment
Share on other sites

Cheesus.. two days before the deadline and I'm starting to get gremlins from the compiler! Suddenly code belonging in a different procedure than I am executing, is running. I might shadow that function out and submit a less complete version than intended.

 

Reason why I'm so late posting a game - I spent the better part of last week trying to figure out a horrible bug that was flickering a sprite of mine (but it worked very well on one emulator nevertheless). Then, I coded around it and "cured it". And then, just for kicks, I commented out that code, and the bug is gone, and that kind of ticked me off to be honest. It's really appaling.

Link to comment
Share on other sites

Yes, just like PuzZLeR I rewrote the code before going to bed. Eventually I will try to make a clean example of what happened, but it looked roughly like this, where x0 was unsigned, x1 and tx were signed:

 

tx = tx + SGN(x1-x0)

 

Changing x0 to signed made no difference. I assigned a temporary variable to the SGN result, and the cross-procedure jumping bug went away. Yes, it sounds entirely bizarre and that is why I want to make a clean example before really submitting a bug report.

Link to comment
Share on other sites

Yes, just like PuzZLeR I rewrote the code before going to bed. Eventually I will try to make a clean example of what happened, but it looked roughly like this, where x0 was unsigned, x1 and tx were signed:

 

tx = tx + SGN(x1-x0)

 

Changing x0 to signed made no difference. I assigned a temporary variable to the SGN result, and the cross-procedure jumping bug went away. Yes, it sounds entirely bizarre and that is why I want to make a clean example before really submitting a bug report.

 

There's something fishy going on in the SGN() function. I see in the resulting Assembly that it tries to do some fancy jumping around but at least one of the jumps seems to land inadvertently on the wrong place.

 

Here's some test IntyBASIC code:

tx  = 5
x1  = 1
x0  = 1

tx = tx + SGN(x1-x0)

FOO = 10
 

And here's the Assembled code from the Listing file:

5255   0280 0110                	MVI V3,R0
5257   0300 010F                	SUB V4,R0
5259   0204 0005                	BEQ $+7
525B   02B8 0001                	MVII #1,R0
525D   0203 0001                	BPL $+3
525F   0300 010E                	SUB V2,R0
5261   0020                     	NEGR R0
5262   0240 010E                	MVO R0,V2
                                	;[30] 
                                	SRCFILE "test.bas",30
                                	;[31] FOO = 10
                                	SRCFILE "test.bas",31
5264   02B8 000A                	MVII #10,R0
5266   0240 010D                	MVO R0,V5

The jump in line $5259, actually lands on $5260, which is the second encoded word of the SUB instruction, which is interpreted as

$5260  010E   SUBR R1,R6

That's gotta freak out the stack. :ponder:

 

It can be better seen in a dissassembly of the running code in the emulator:

> u
 $5255:    0280 0110              MVI  V3 ($0110),R0                    | tx = tx + SGN(x1-x0)                             
 $5257:    0300 010F              SUB  V4 ($010F),R0                    | tx = tx + SGN(x1-x0)                             
 $5259:    0204 0005              BEQ  $5260                            | tx = tx + SGN(x1-x0)                             
 $525B:    02B8 0001              MVII #$0001,R0                        | tx = tx + SGN(x1-x0)                             
 $525D:    0203 0001              BPL  $5260                            | tx = tx + SGN(x1-x0)                             
 $525F:    0300 010E              SUB  V2 ($010E),R0                    | tx = tx + SGN(x1-x0)                             
 $5261:    0020                   NEGR R0                               | tx = tx + SGN(x1-x0)                             
 $5262:    0240 010E              MVO  R0,V2 ($010E)                    | tx = tx + SGN(x1-x0)                             
 $5264:    02B8 000A              MVII #$000A,R0                        | FOO = 10                                         
 $5266:    0240 010D              MVO  R0,V5 ($010D)                    | FOO = 10                                         

You can see that in line $5259, the target address of the "BEQ $+7" instruction has been computed as $5260 instead of $5262 (skip the subtraction and negation, and store the zero).

 

As you discovered, assigning the SGN() function value directly to a variable avoids the mess:

 

In IntyBASIC:

FOO = SGN(x1-x0)
tx = tx + FOO
 

In Assembly:

> u
 $5255:    0280 0110              MVI  V3 ($0110),R0                    | FOO = SGN(x1-x0)                                 
 $5257:    0300 010F              SUB  V4 ($010F),R0                    | FOO = SGN(x1-x0)                                 
 $5259:    0204 0005              BEQ  $5260                            | FOO = SGN(x1-x0)                                 
 $525B:    02B8 0001              MVII #$0001,R0                        | FOO = SGN(x1-x0)                                 
 $525D:    0203 0001              BPL  $5260                            | FOO = SGN(x1-x0)                                 
 $525F:    0020                   NEGR R0                               | FOO = SGN(x1-x0)                                 
 $5260:    0240 010D              MVO  R0,V5 ($010D)                    | FOO = SGN(x1-x0)                                 
 

Now the jump at $5259 lands correctly at $5260, just as the computer gods intended. It's precisely the clever code that tries to continue with the expression by adding/subtracting the result to the next operand, which causes the problem. It doesn't account for the length of that instruction (2 words) in the jump.

 

This is a bug. I recommend to everyone to always assign the return value of SGN() directly to a variable until it is corrected in the compiler.

 

Oscar, a quick and easy solution to these things is to inject labels at judicious places during code generation, and branch to those instead. That's what I do in P-Machinery, rather than assuming the length of the instructions generated, since that is always a bit dangerous. :o

 

-dZ.

  • Like 1
Link to comment
Share on other sites

P.S. The bad landing depends on various conditions for it to freak out the stack. For instance, in my test sample above, the value of R1 happened to be zero, so nothing happened. However, I could see that in some circumstances when it is not, it will alter the stack inadvertently, causing the return of your sub-routine to jump into the weeds.

 

 

Also, I will propose to the other judges to extend the length of the contest if that's what people want. :)

 

-dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

Wow! I thought it was me who had screwed up, and then you were able to replicate the issue so quickly!

 

While this is not the thread for IntyBASIC bug reports, while someone is looking at SGN for the next release of the compiler, consider having another look at ABS too. Nanochess explained earlier why ABS didn't work out the way I thought it would, which is why I replaced it with a SGN function elsewhere, but it would seem to me that both should have the capacity to operate correctly no matter which size the input and output variables are.

Link to comment
Share on other sites

Wow! I thought it was me who had screwed up, and then you were able to replicate the issue so quickly!

 

While this is not the thread for IntyBASIC bug reports, while someone is looking at SGN for the next release of the compiler, consider having another look at ABS too. Nanochess explained earlier why ABS didn't work out the way I thought it would, which is why I replaced it with a SGN function elsewhere, but it would seem to me that both should have the capacity to operate correctly no matter which size the input and output variables are.

 

What's the problem with ABS()? In the case of SGN(), the size of the variables is inconsequential (as you noticed in your own test). It's actually the size of the assembled instructions that cause the bug. The SGN function works something like this:

  ' SGN(x)
  tmp = x
  If (tmp = 0) Then
    Goto Skip
  End If

  tmp = 1
  If (x > 0) Then
    Goto Skip
  End If

  tmp = tmp * -1

Skip:
  x = tmp

That "Goto Skip" is actually a computation of "Jump the number of addresses until you land after the instruction that negates tmp."

 

That works out well when you just have SGN() by itself. However, when you include it in a longer expression, it tries to be smart and take the value of "tmp" and apply it to the next operand (adding it or subtracting it as necessary) -- yet the length of the jump instruction is not adjusted. It then looks something like this:

  ' y = y - SGN(x)
  tmp = x
  If (tmp = 0) Then
    Goto Skip
  End If

  tmp = 1
  If (x > 0) Then
    Goto Skip
  End If

  ' Since tmp should be negative and we are going to
  ' subtract from "y," we just add it to "y"
  tmp = y + tmp

Skip:
  x = tmp

Except that "Skip" this time is actually pointing to somewhere in the middle of the "tmp = y + tmp" code.

 

It turns out that the negation instruction (NEGR) assembles to a single word, but the SUB/ADD from memory takes two words. That causes the computed branch instruction to fall into the middle of the SUB/ADD instruction, which the CPU dutifully decodes as some other completely different single-word instruction, which happens to be an operation on the stack. Depending on the contents of a particular register, this operation can be destructive or innocuous. As your experience shows, it's more than just a theoretical issue. ;)

 

-dZ.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...